Bite the bullet and add a special purpose boolean option to control
game behavior for random clairvoyance. When objects or monsters are
discovered, it normally issues "you sense your surroundings" and
performs a getpos() operation which allows the player to browse the
map by moving the cursor around and getting 'autodescribe' feedback.
But there have been complaints that once the hero has the Amulet
(which triggers random clairvoyance even though hero isn't flagged
as having that attribute) the message and pause-to-browse become too
intrusive.
This was initially combined with the 'timed clairvoyance' fix because
they both bump EDITLEVEL to invalidate existing save files, but their
details don't interact so I separated them.
When the hero has random clairvoyance, the code used
| (moves % 15) == 0 && rn2(2) != 0
(where 'moves' is actually the turn number) to decide when it would
kick in and show a portion of the map. If the hero was fast enough
to get an extra move when the turn value met the (moves % 15) == 0
condition then clairvoyance could happen twice (or more if poly'd)
on the same turn.
The changes (one new field, reordering a few others) in 'struct
context' invalidate existing 3.7.0-x save files.
Fixes#266
Build feedback filtered by a script which filters out -Dthis -Wthat:
gcc -g -I../include -I../lib/lua-/src -c ../win/share/tilemap.c
The second -I is obsolete or else its bogus value would have caused
build failure. When removing it, I noticed that there was still quite
a bit of obsolete yacc and lex stuff in there. Remove that too.
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
Add hallucinatory trap names
This adds many funny, realistic, and nonsensical traps to the game, to
be shown when the player is hallucinating.
Architecturally, the biggest change is merging the what_trap macro and
the "defsyms[trap_to_defsym(ttyp)].explanation" pattern into a single
function "trapname", which returns the name of the trap, handling the
hallucination case. There is also a second parameter used for overriding
hallucination in the occasional cases where the actual trap name should
always be returned.
In addition, the what_trap and random_trap macros are now obsolete and
not used anywhere, so they are removed.
reinstate anti-rng abuse bit on hallucination
updates to hallucinatory trap names and fixes37.0 entry
Poly'd hero hiding on the ceiling was told "you can't go down here"
if using '>' at a spot that didn't have down stairs, trap door, hole,
or pit. Let '>' bring a ceiling hider out of hiding; lurker above
resumes flying, piercer falls to floor or whatever is underneath it.
Fix some issues noticed when experimenting with ceiling hiders.
They're all blind (at least without the monks' Eyes) and some of
the behavior while blind seemed to be incorrect (though some that
I thought was wrong turned out to be ok; feel_newsym() won't update
the map if the hero can't reach the floor). Fixing that made me
notice that some terrain side-effects (being underwater or stuck in
lava) weren't getting disabled when the underlying terrain wasn't
the corresponding type anymore.
