display.h -- bring an unused macro up to date
detect.c -- always call newsym() when searching or secret door
detection finds a trap rather than just when not blind
glyphs.c -- some formatting
pager.c -- lookat() behaves very strangely when single-stepping
in the debugger (gdb); this didn't help
The old secret door detection just redisplayed locations with
discoveries (secret doors and traps, mostly). Somewhere along the
line it was augmented to find hidden monsters and to deliver one or
two messages reporting how many things had been discovered. Now it
has been augmented again, to find trapped doors and chests, and to
supply a message when the detection attempt fails to find anything.
More substantially, it highlights the relevant locations as they're
found, before the feedback message(s).
Initially I was using tmp_at() to mark all significant locations,
but that required --More-- and for player to acknowledge it when
detection was done. That would probably be ok for wand of secret
door detection and spell of detect unseen, but it would be a hassle
for ^E. It's been revised to use flash_glyph_at() [previously only
used when ^G creates unseen monsters, I think].
The new behavior seems to be working reasonably well. For curses,
the 'timed_delay' option must be set. flash_glyph_at() calls
flush_screen() between its output and nap in each cycle of multiple
flashes, but that evidently isn't sufficient for curses. Maybe
curses init should just force on 'timed_delay'.
I've left the tmp_at() stuff in. We might want to modify things to
use it instead of flash_glyph_at() when the accessibility flag is
set. Its current compile-time selection won't be adequate though.
^E and wand of secret door detection used to just update the map
without any other feedback, but were changed post-3.6 to issue a
message about what things are being discovered. But the message is
misleading if [some of] the things revealed are obscured by objects
or by monsters. Presumeably by regions too.
While trying to track down a display problem with regions
[when a monster is shown over a region because the hero is
adjacent, it doesn't revert to the region's cloud glyph when
hero moves farther away; that's not resolved yet],
I discovered a different display problem for the same thing. If
you pick a #terrain choice that keeps traps it is supposed to show
region spots too, but that didn't work when there was a monster at
the same spot. It removed the monster but showed background there.
Issue reported by elunna: none of the display choices for #terrain
offered a way to show the terrain beneath temporary gas/cloud
regions (except "full map" in wizard mode or explore mode). That
prevented the command from being used to find stairs and portals
which had been mapped before becoming covered up.
Adding extra menu choices to deal with visible regions would result
in #terrain becoming a mess. Instead, treat regions as if they were
traps. Picking a choice that includes traps will show region spots
which are in view as cloud or poison cloud, picking one that excludes
traps will show the underlying terrain. Region spots which aren't
within view are handled the same as before: whatever the hero
remembers at their location gets displayed.
The default menu choice excludes traps so will display stairs that are
covered by gas cloud regions, but not portals, same as when no regions
are present. When showing traps and one is covered by a gas cloud,
the trap will be shown rather than the gas cloud, making it possible
to see known portals.
At the moment the new "#terrain handles regions like traps" feature
hasn't been documented anywhere. That might get rectified someday.
I'm not sure whether trap detection ought to also detect regions now.
This doesn't attempt to tackle that and I think that I'll pretend
that the idea never occurred to me.
'parnoid_confirm:traps' definitely ought to prompt for confirmation
when entering a visible harmful region. This doesn't add that.
Bonus fix: it's possible for a visible region to cover up a not yet
explored location. Searching next to such a spot wasn't changing the
spot to be marked as explored (unless hero was blind). Now it will.
Fixes#1262
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
Have magic mapping add special rooms to known overview data. Only
affects shops and temples because they're the only rooms tracked.
Most other special rooms revert to normal rooms as soon as they're
entered so there wasn't any point in tracking them. That might no
longer be the case.
Wand of probing zapped at or through a shop door or even at a shop
wall will add the shop annotation to the overview data. That works
differently for normal shops than for subrooms in the twin business
theme rooms. I'm not sure whether any fixing is needed there since
the shop type information gets suppressed as soon as more than one
shop becomes known on a level.
Adds a new boolean option, accessiblemsg. If on, some game messages
are prefixed with direction or location information, for example:
(west): The newt bites!
(northwest): You find a hidden door.
I added the info to the most common messages, but several are
still missing it.
Update several places where lazy lastseentyp[] might be an issue.
I think it isn't updated in a timely fashion when newsym() shows
a spot covered by an object or trap, but didn't manage to find any
cases where that caused a problem. This is more in the nature of
a precaution.
From a comment w/ diff in the pull request by entrez, combine the
show-full-map flag (available in wizard mode and explore mode) with
the bitmask for map-only, map-and-traps, map-and-traps-and-objects
flags for #terrain mode (and getpos() help) instead of passing that
as a separate argument. No change in behavior unless I messed up.
b_trapped was treating 0 as a null value for its bodypart parameter, but
0 is actually the value of ARM, so b_trapped(..., ARM) would be treated
as intending no A_CON abuse. Add NO_PART = -1 to the bodypart_types
enum, and use that instead of 0 as the "no body part" value in
b_trapped, so that ARM can be passed to it without any ambiguity.
aosdict identified this issue in xNetHack and handled it differently; he
added NO_PART with a value of 0, incremented the existing bodypart_types
values, and padded the body part arrays so the actual body parts would
start at index 1. I think using NO_PART = -1 is simpler, but that's an
alternative approach that can be used instead -- it is advantageous in
that it automatically fixes any other places where 0 is assumed to be a
non-body-part value that I may have overlooked.
When lastseentyp[x][y] is different from levl[x][y].typ and #terrain
tries to show <x,y>, the value of levl[x][y].flags might not have an
approrpriate value for the remembered terrain type. The reported
problem was an impossible() about wall mode.
rm.wall_info == 4 corresponds to rm.doormask == D_OPEN and both of
them are overloaded on rm.flags. A spot remembered as a wall but
actually a secret door might cause this if it has become discovered
('wall' changed to closed door) and then opened (with door intact)
while out of view. [I'm not sure how that could happen though.]
I was unable to reproduce it so haven't verified that the fix works.
I was working on this at the time 3.6.0 was released and set it aside
until later. Later has finally arrived. Redo the Blind, Blinded,
Blindfolded,&c macros to make more complete use of intrinsic property
handling. Blinded was being treated as a number which could be added
to or subtracted from; now that has to be done via TIMEOUT mask
because it has FROMOUTSIDE (OPTIONS:blind) and FROMFORM (poly'd into
!haseyes() form) bits included. Object definitions for blindfold and
towel now specify the BLINDED property; overriding blindness via the
Eyes of the Overworld is accomplished via props[BLINDED].blocked.
Code generated for the scores of Blind and !Blind tests throughout
the program should be smaller.
One bug that has been fixed is that putting on the Eyes of the
Overworld cured permanent blindness (from OPTIONS:blind). The
u.uroleplay.blind flag was cleared and stayed so after taking them
off. Putting the Eyes on still breaks blind-from-birth conduct but
now blindness will resume when they are removed.
This was untested at the time it was set aside and is only lightly
tested now. A large number of the changes here are just to switch
from Blinded to BlindedTimeout for current timed value and to call
set_itimeout() for setting a new value.
1. Add "engraved room floor" pchar sym (S_engroom). The symbol that
displays at the engraved part of a room (not a corridor though).
The default symbol is '`' which is currently never shown if people
have defined the boulder symbol to '0' and statues are displayed as
monster symbols. It is bright blue.
Add some stylized variations of the S_engroom symset to some of
the symsets.
2. Add "engraved corridor" pchar sym (S_engrcorr). The symbol that
displays at the engraved part of a corridor. The default symbol is
'#', and it matches the symbol for corridor from for whatever the
current symset uses. It is bright blue to match the color of the
S_engroom symbol. Using the normal corridor symbol for display
preserves the lines of the corridor so is not as visually-disruptive
as a smaller symbol would be. Explicit entries that match the S_corr
symbol have been added to the symset file.
Magic mapping and clairvoyance impacts yet to be determined.
The Guidebook updates will come later.
Autodescribe was not updating during browse_map() when the cursor was
moved over a gold glyph that was actually a trap, causing the trap to
be described as the previous square that the cursor was on (probably
"unexplored area") instead of as gold pieces. This was especially
noticeable when using OPTIONS=whatis_coord:m, because the coordinate
was not updating when moving the cursor over the trap.
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
Suggested by entrez: when you search while engulfed the feedback asks
whether you're looking for the exit, but the joke about the exit isn't
funny when repeated over and over which happens if the player waits to
be expelled by using 's','s',... rather than '.','.',....
When zapping a wand of secret door detection or casting spell of
detect unseem instead of displaying
|You reveal secret doors.
|You reveal a secret corridor.
|You reveal traps.
|You reveal a hidden monster.
show
|You reveal 2 secret doors, a secret corridor, 3 traps, and a hidden monster.
as a single message.
Detecting invisible monsters is still a separate message; those get
re-mapped as "remembered, unseen monster" but not actually revealed.
The pull request included some changes that were neither accidental nor
unintentional, so only a subset of the changes from pull request #869
submitted by klorpa were manually applied.
behaviour -> behavior
speach -> speech
knowlege -> knowledge
incrments -> increments
stethscope -> stethoscope
staiway -> stairway
arifact -> artifact
extracing -> extracting
The uses of "iff" were left alone.
Close#869
I was never too happy with how this was a silent effect that required
you to watch the map to see if anything changed. It might count as
an accessibility issue as well, not sure.
This change adds specific feedback for all the possible things that
might get revealed by detecting unseen. If you reveal a secret door or a
trap, you now get a message indicating that.
One slight behavior change here: if the only thing detected is invisible
monsters, the game previously did not return a result of "detected
a non-zero number of things" to the caller of findit(); now it does.
(This allows the wand to be automatically identified when it prints a
message about detecting invisible monsters.)
If you had both warning and ESP, you would get the message "Your danger
sense causes you to take a second look close by" when moving next to a
monster that is technically "undetected" (according to mundetected) but
was actually apparent to the player via ESP. For instance, moving next
to an eel hiding in the water would produce this.
Since there was no follow-up message ("You find a <monster>".) and no
new information being given to the player, the "danger sense" message
was pointless, and so I removed it in this case when the warning doesn't
lead you to find anything new.
Change trappers and lurkers above to remove digestion damage. They
fold themselves around rather than swallow the victim. There were
are lot of places that assumed that an engulfer which is an animal
would swallow and digest the victim. In hindsight, it might have
been simpler to take the M1_ANIMAL flag off of trappers and lurkers
above.
This adds a new digests() predicate for creatures with AT_ENGL+AD_DGST
(purple worm) and also enfolds() for AT_ENGL+AD_WRAP (both 't'-class
critters).
There are several minor fixes mixed in with this. I didn't record
them as I went along but the two I remember are
1) if poly'd into a holder and holding on to a monster, the '<' and
'>' commands refursed to work; release the held creature first
and then treat those commands as normal;
2) throwing a non-weapon while engulfed by an ochre jelly reported
"the <item> vanishes into the ochre jelly's /currents/".
This needs a lot more testing. I found and fixed multiple minor
details before my own testing burned out.
Because back_to_glyph assumes the hero can directly see the spot, when
used for #terrain (e.g. when a spot was covered by a remembered object)
it would display corridors as lit if lit_corridor was enabled. Instead
of trying to suppress back_to_glyph's S_litcorr result only under
circumstances where it would be unusual, just show all corridor spots
with S_corr, so that none of them appear as "lit corridor". This
is consistent with what is already done for room spots for #terrain
(S_darkroom is forced to the basic S_room across the board).
This replaces the old pushq/saveq arrays (which were used to save
the keys pressed by the user for repeating a previous command)
with a new command queue. This means there's no hard-coded limit
to the saved keys, and it can repeat extended commands which are
not bound to any key.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
Switch to using a macro invocation Verbos(n, s) in place of the
flags.verbose checks.
Provide the mechanics for individual suppression of any of the
existing messages that were considered verbose.
Mechanics only - this code update does not provide any means of
setting the suppression bits.
iflags.verbose = 0
is still a master suppression of all the verbose messages.
iflags.verbose = 1
turns on the verbose messages only for those whose suppression
bit is 0 (not set).
instead of as fake bear traps
Use the new traps and their tiles when confused gold detection finds
trapped doors and trapped chests. (Large boxes can be trapped too;
they use the trapped chest trap and corresponding tile rather than
have their own.)
Usually these pseudo-traps go away when as soon as they are within
line of sight. (While testing, I noticed that seeing a trapped door
from outside its room rather than inside didn't behave that way.
The door was created by wizard mode wishing; I don't know whether
that was a factor.)
I also discovered that secret doors weren't being handled correctly.
They can't be trapped because of their use of both the doormask and
wall_info overlays of levl[][].flags, but I had a secret door be
falsely displayed as a trap. This fixes that.
We should have obj->tknown and rm->D_TRAPKNOWN so that the hero won't
forget about these traps after declining to attempt to untrap them.
But that's more work than I care to tackle.
Cursed potions of object detection were showing all mimics disguised as
statues as 'i' glyphs, because object_detect used PM_TENGU as the
corpsenm of any mimic disguise. Instead, use MCORPSENM when available
so that hidden mimics will be mapped with glyphs corresponding to their
actual disguises.
Instead of returning 0 or 1, we'll now use ECMD_OK or ECMD_TURN.
These have the same meaning as the hardcoded numbers; ECMD_TURN
means the command uses a turn.
In future, could add eg. a flag denoting "user cancelled command"
or "command failed", and should clear eg. the cmdq.
Mostly this was simply replacing return values with the defines
in the extended commands, so hopefully I didn't break anything.
