When clairvoyance revealed an underwater object and the player wasn't
being given a chance to browse for some other reason, the map didn't
get refreshed and the object stayed displayed with the water hidden
under it. Force a chance to browse when revealing underwater objects
despite that being intrusive when clairvoyance kicks in while walking
around.
Prevent food detection--scroll or crystal ball--from noticing the cat
corpse inside SchroedingersBox since its presence is tentative and
resolving its status during detection is a huge can of worms (live cat
placement on map from inside locked box, parallel resolution required
for monster detection/warning/telepathy that would render the box
fairly useless since it would probably end up getting resolved by ESP
before hero gains access).
Prevent cat corpse in the Box from being added to shop bill if unpaid
Box is picked up. That prevents it from being listed as a bought item
if the player buys the box (instead of being described as unknown
contents; an older, more general bug which still hasn't been fixed).
As far as I'm aware, off the revised handling of Schroedingers Cat is
finished.
and over the hero. 3.6.0's clairvoyance tried to show things in
a non-standard sequence, which was intentional but had unintended
side-effects like the disappearing monsters complained about in the
report. To make it work as intended would have required --More--
whenever it kicked in, which is much too intrusive when it happens
every N turns rather than when explicitly casting the spell.
Redo it substantially, and give preference to monsters over objects,
objects over traps, and traps over underlying terrain like normal
vision-based display does. It now detects all monsters within its
bounding box but shows ones which aren't directly in view as
"unseen monster" unless via spell cast at skilled or expert, or at
basic when also having intrinsic clairvoyance.
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.
Fixes#38
In 3.6.1, some code in mfind0(detect.c) was mis-indented in a way
which suggested that the grouping within braces might not be what was
intended, and that was right--there was a pair of braces missing when
compared with older versions of the code involved. A previous patch
(post-#38) had changed the indentation to match the surrounding braces
without really addressing the issue. But it turned out not to make
any difference either way since mundetected is only used by hiders
and eels. This reorganizes the relevant code to make it simpler to
understand, I hope.
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.
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.
When writing the known portion of the current level's map into
dumplog, discard any blank rows at the top (there will already be
one blank line separating it from the text that precedes) and keep
at most one blank row at the bottom (sometimes there won't be any).
Temporary map views for detection or #terrain allow moving the cursor
around to get the brief location description provided by getpos's
autodescribe feature and were doing so by forcing the 'autodescribe'
option to True, then leaving it that way. Save the option value prior
to such operations and restore it after instead of leaving it changed.
Change most instances of detection to offer the player a chance to
move the cursor around on the map so that the getpos() autodescribe
feature can explain things that might go away as soon as the
current detection completes. The few instances that don't offer
such a chance are the ones where everything which has been revealed
will still be there once the action finishes (such as regular magic
mapping and blessed/persistent monster detection).
There were quite a lot of inconsistencies in things like handling
for detection while swallowed or underwater. I didn't keep track
of them to distinguish between 3.6.0, current dev code, or my patch
in progess. They should be much more consistent now but without a
comprehensive fixes36.1 entry.
Blessed clairvoyance (divination spells at skilled or expert) now
shows monsters as well as terrain. I first had it like that for
any clairvoyance, but having getpos/autodescribe kick in every 15
or 30 turns once you have the amulet--or pay the appropriate amount
to a temple preist--was nearly unplayable. When it only follows an
explicit spell cast it is not intrusive.
When confused gold detection finds a door trap or a chest trap, it
puts a bear trap glyph/tile on the map at that location. (They
disappear once they're within sight.) Those should be given their
own glyphs so that they can have their own tiles, but this doesn't
do that. What it does do is describe such fake bear traps as
"trapped door" or "trapped chest" when examined with far-look.
The '^' command--if used while blind so that '^' hasn't disappeared
yet--needs to catch up: it says "I can't see a trap there" when the
adjacent '^' is a fake bear trap.
View the regular map, as originally intended, when using #terrain
while underwater. Doing so means you can't see an underwater object
underneath an adjacent critter by viewing map+traps+objs (without
monsters), but being able to see the level map instead of just the
8 adjacent squares is more valuable.
Requested during beta-testing however long ago: want a way to
look at specific map locations while #terrain is showing them
without monsters and/or objects and/or traps being displayed in
the way. The post-3.6.0 autodescribe feature for getpos() made
this pretty easy to achieve, although the lookat() aspect felt
more like trail-and-error than careful design.
Instead of putting up a --More-- prompt, ask the player to pick
a location with the cursor. Moving the cursor gives the terse
description for every location traversed. Actually picking a
spot just ends #terrain and goes back to normal play.
Discovered while working on an enhancement to #terrain....
Various detect magic (objects, food, &c) performed while underwater
temporarily removes the hero from the water in order to have access
to the regular map. In 3.4.3, a hangup save during the detection
would leave the hero standing on top of the water. 3.6.0 added a
flag to track should-be-underwater so that during a hangup save the
hero could be put back in when going into the save file. It also
added #terrain, another situation that uses the remove-from-water
hack while manipulating the map.
The flag wasn't being cleared after use, only during save, so normal
play without a hangup left it pending until next regular save. The
result being that after restore, the hero would be considered to be
underwater again regardless of current location, and the map display
would be limited to a view of the adjacent spots as if underwater.
Then, any move--even using '.' to rest--would notice that the
'underwater' hero was not at a water location and put things back to
normal, with feedback of "you are on solid land again." So to the
player, this would seem like a pair of map display and nonsequitor
message issues, not the internal logic one it actually is.
Changes to be committed:
modified: include/extern.h
modified: src/allmain.c
modified: src/detect.c
modified: src/display.c
Bug bz22 (no corresponding web id) reported quite some time ago.
Reported:
Warning stays on when a "lurker above" is co-located with a
boulder, even when you are adjacent to the spot. Even though
you see the warning symbol and not the boulder, an attempt
to move in that direction tries to move the boulder, rather
than attack the creature you know to be there. What's more,
you can get the
"You hear a monster on the other side of the boulder..."
preventing anything from happening if there is a monster on
the other side of the spot. The player doesn't necessarily
even know there is a boulder there at the time (because
warning trumps the boulder display) so it can all be somewhat
confusing.
Change:
- Split off a section of the search0() code for monsters into
a separately callable function, arbitrarily named mfind0(),
which takes a special arg for this particular scenario.
- If you have Warning and you get adjacent to an unseen hider
such as a lurker above with the Warning glyph still displayed,
a specific search is carried out for the obviously present monster.
- The boulder concerns in the original report should become moot
after this.
Also #terrain command with dark_room on showed lit room floor on places with
objects or traps. We don't want to show dark room symbol anyway, because
the dark room symbols are only for line-of-sight, and #terrain should
override that...
Reformat some trailing &&, || operators followed by end-of-line comment,
missed by the earlier continuation formating.
An
#if 0
something {
#else
something_else {
#endif
construct in rhack(cmd.c) confused the automated reformatter, resulting
in some code from inside a function ending up in column 1.
Replace instances of strings split across lines which rely on C89/C90
implicit concatenation of string literals to splice them together
with single strings that are outdented relative to the code that uses
them. It's uglier but it won't break compile for pre-ANSI compilers.
This covers many files in src/ that only have one or two such split
strings. There are several more files which have three or more. Those
will eventually be '(2 of 2)'.
Noticed along the way: the fake mail message/subject
Report bugs to devteam@nethack.org.
wasn't using its format string of "Report bugs to %s.", so would have
just shown our email address. Doesn't anybody enable fake mail anymore?
I modified that format to enclose the address within angle brackets and
made a similar change for the 'contact' choice of the '?' command.
Make the post-3.4.3 '#terrain' command be more versatile by allowing the
player to choose between floor-only, floor+traps, and floor+traps+objects
so that it is possible to view known traps covered by objects or monsters
and remembered objects covered by monsters. The extra explore mode and
wizard mode choices aren't affected.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
There is a lot of code affected by this, and Pat Rankin correctly
observes that it would be better to store roguelike as a level flag
rather than just using Is_rogue_level. A note for the future.
^F on Plane of Water didn't show the magic portal to Astral. I spent
a lot of time looking at differences between current code and 3.4.3 to figure
out what had changed, then finally tried it on 3.4.3 and discovered that it
didn't work back then either. ^F marks all floor and ceiling traps as seen
and explicitly maps them, but Water has level.flags.hero_memory clear, making
the mapped trap disappear when it isn't in line of sight.
When fixing this, I changed magic mapping so that it shows furniture
(stairs, altars, fountains, &c) in preference to traps or objects, and known
traps in preference to objects, so hidden things can be spotted. (Once
they're in line of sight, the precedence reverses to normal, showing objects
on top of traps on top of floor.)
Change the post-3.4.3 extended command "#terrain" so that it can be
used in normal play rather than just in wizard mode. It's inspired by
a command in 'crawl' that lets you view the bare map without monsters,
objects, and traps so that you can see the floor at locations which have
been covered up by those things.
normal play
redraw map to show the known portion of it without displaying
monsters, objects, or traps; after player responds to --More--, the
map returns to normal.
explore mode
put up a menu so player can choose between the known portion of
the map as above or the full map. If the level isn't fully explored
then the latter provides information to the player that he hasn't
earned yet, but the _hero_ doesn't learn anything and after --More--
the map reverts to what it showed before. (In other words, unlike
with magic mapping, the unknown portion doesn't become known.)
wizard mode
put up a menu so player can choose among four alternatives: the
two above, the text representation of the map's internal levl[][].typ
codes, or a legend explaining those codes. (Originally, I wanted to
be able to toggle back and forth between these last two, but looking
at one and dismissing it, then reissuing #terrain to look at the
other is much simpler to implement and is good enough.)
Redo the fix that prevents hangup from putting hero on top of water
if it occurs during magic mapping or object/gold/trap detection. Instead
of copying u.uinwater into another field in struct u so that it can be
reset during restore, copy it into a new field in struct iflags and reset
it during save so that no fixup upon restore is needed.
Noticed while looking at the magic mapping code: u.uinwater is
cleared during mapping and detection so that map updating isn't suppressed
due to underwater vision restrictions, and it was possible for a hangup
save to take place before that state field was reset. After restore, the
hero would end up standing on water, then fall in on the next turn. This
saves it in struct `u' rather than in a local variable, so that the stored
value is accessible during restore.
The u.uburied flag was being ignored, but presumeably it would also
impose severe vision restrictions if it ever gets implemented, so it is
now saved, temporarily cleared, and restored along with u.uinwater during
monster/object/gold/trap detection and magic mapping.
From a bug report, he was running blind while wielding scissors--
I mean Excalibur--and stopped for no apparent reason. The autosearch
capability conferred by that artifact (also by ring of searching, or for
some roles or races once they reach a particular level) had found a secret
door and changed it into a normal door, but since he couldn't see at the
time his map display wasn't updated to show that. This makes the map show
such things even if blind, and also gives a message that the search found
something.
Simplify many of the intrinsics macros from
#define xxx_resistance (Hxxx || Exxx || resists_xxx(&youmonst))
down to
#define xxx_resistance (Hxxx || Exxx)
by setting or clearing an extra bit in Hxxx during polymorph so that the
resists_xxx() check becomes implicit.
Unfornately there were lots of places in the code that treat Hxxx
as a timeout number--primarily for Stunned, Confused, and Hallucination;
Stunned happens to be one of the revised macros--rather than as a bit
mask, so this patch needed a lot more changes than originally antipated.
