struct rm.flags in overloaded for a bunch of rm.typ -dependent things
(doormask, altarmask, throne/fountain/sink looted, a few others) and
wasn't being reset for various cases where rm.typ gets changed.
I've changed a lot, some no doubt unnecessarily, and probably missed
plenty. This compiles but has not been thoroughly tested.
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)
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
Make #untrap while carrying the non-cursed (for rogues) or blessed
(for non-rogues) Key work the same as #invoke has been doing (without
regard to its bless/curse state): when used on trapped door or chest,
that trap will always be found and disarming it will always succeed.
It should work when carried by monsters too: if they try to open a
trapped door while carrying the Key (must be blessed since they're
not rogues) the trap will be automatically disarmed. (Caveat: that
hasn't been adequately tested.)
TODO (maybe...): change the #invoke property to detect unseen/secret
door detection instead of #untrap. The latter isn't completely
redundant; it works when the Key is cursed. But quest artifacts
strongly resist becoming cursed so that isn't a particularly useful
distinction.
Also, trap hints when wielding the Key without gloves didn't notice
adjacent door and chest traps. Now it does. And the behavior is
slightly different: known traps covered by objects or monsters are
treated like unknown traps as far as the hot/cold hints go.
Always find traps when using the rogue's quest Key to lock or unlock a
trapped door or chest provided that the Key is not cursed (for rogues)
or is blessed (for non-rogues). When a trap is found, the player is
given the opportunity to disarm it, and doing so will always succeed.
(It isn't disarmed automatically; the player may prefer to leave traps
in place, presumably hoping to set up a dangerous bones file. Or he
or she may be unaware of the guaranteed success and be too timid to
risk trying to disarm the trap.)
TODO: make #untrap of a door or chest while carrying that Key always
find traps (with same bless/curse requirements as above). And maybe
change its #invoke property from untrap to detect unseen/secret door
detection since current invoke power would become redundant.
Also, move a bunch of new artifact abilities from the fixes section to
the new features section in fixes36.1.
When travel fails to reach its destination, it remembers the target
spot to use as default next time. But that spot is only meaningful
on the current level. Discard last travel destination when moving
to a different level.
Also, discard unlocking context when changing level unless the
context is for a container being brought along (after having been
picked up since you can't unlock a carried box). Previously, a
door pointer on the new level could happen to match the last one
being unlocked on the old level.
Discard trap setting context when changing level even if the trap
object is brought along.
Somehow the code for applying a touchstone got inserted in between
two sections of code for applying a trap (ages ago; probably since
touchstone was first introduced however many versions back), so
clean that up.
Fixing up mis-indented block comments, but hit some files that hadn't
had the earlier mixture of tab replacement, etc, so it's bigger than I
expected. If I get to it, they'll be another round of this tomorrow.
Same sort of stuff as before: some continuation lines with operator
followed by end of line comment (only a few files with those still to
go...), plus tab replaced by spaces in comments, excess parenthesis
removal for return statements, and force function name to be in column
one in function definitions:
type name(args) /* comment */
argtype args;
{
to
/* comment */
type
name(args)
argtype args;
{
I've been spotting those by eye rather than rexexp, so probably missed
some.
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.
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!
From ais523's recent list of bugs:
If a long worm tail is blocking the door, and you're blind and not
telepathic, attempting to close the door marks the position of its head.
From an email received in late September 2014 before the git conversion:
> I was trying to close a door, not noticing that there was a garter
> snake there, and this message resulted:
> The garter snake stands in the way!
> I haven't tried it with any other monsters without feet, but
> "stands in the way" appears to be the wrong way to describe
> this situation...
Both of the above were found in the same function in lock.c
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.
Suggested by <email deleted> a month ago when he
reported that attempting to unlock a door which was actually a mimic
simply told the player that the door was not locked or that there was
no door. He thought that mimic should take the key/pick/card away from
the hero. This gives a 50% chance for the unlocking tool to be stolen
and become part of the mimic's inventory; it will be dropped when mimic
is killed.
The theft routine has groundwork to be able to be used to take the
hero's wielded or thrown weapon when hitting, but the attack code doesn't
call it so that won't happen (and the theft code hasn't been tested under
that circumstance). I'm not sure whether mimics should be able to grab
weapons, but g.cubes perhaps should, and if puddings could then "pudding
farming" [using a low damage iron weapon to split puddings, yielding tons
of experience, death drops, and #offer fodder when they're killed and
repeatable for as long as at least one pudding is kept healthy enough to
be split again] would become tougher to accomplish. [The item drop and
corpse aspects have been toned down quite a bit since 3.4.3, but with
sufficient patience it is still possible to abuse.]
I started to add handling for doorways containing mimic-as-boulder
to doopen() and doclose() as was done for pick_lock(), but decided that
it was better just to prevent mimics from appearing as boulders at closed
door locations in the first place. So the most recent pick_lock() change
and its fixes entry go away.
This also fixes a post-3.4.3 bug. On the top level of Sokoban I
discovered a boulder over a hole; probing reported it as a mimic with
0 hp. The special level loading code moves mimic-as-boulder away from
trap spots by using place_monster() to put it on another spot, but it
was missing the corresponding remove_monster() to take it away from the
original location so left a stale pointer on the map.
Reported five months ago by <email deleted>,
the top level of Sokoban has mimics who pose as boulders and if one was
in a doorway (treasure zoo at final destination) you could still unlock
the door there without waking the mimic. Yesterday's fix for unlocking
a door which was actually a mimic posing as one didn't handle this case.
From a bug report, attempting to use a key,
lock pick, or credit card on an open doorway that contained a mimic posing
as a closed door reported "that doorway has no door" or "you cannot lock
an open door" as if no monster was present, and failed to find the mimic.
Fix a bug From a bug report: while stunned he tried to close
an adjacent open door and when his choice of direction got changed to
some non-door spot, no time elapsed so he could just keep repeating the
attempt until eventually getting the correct direction. Trying to open
an adjacent closed door and trying to remove the saddle from an adjacent
monster via #loot behaved similarly. Applying keys and lock-picks also
did so in 3.4.3, but had already been changed to use up time in the dev
code. There may be other actions which need fixing.
The dungeon_overview bits in the rm structure were being
clobbered by a run-length encoding save/restore because
they weren't taken into consideration.
This patch pulls that data out of the rm structure completely.
It also adjusts the run-length encoding checks to take the
candig bit into consideration and adds a comment to rm.h
reminding people to make run-length encoding adjustments
in save.c for any new bits that get added.
From a bug report, attempting to open or close
a door while blind didn't always update the map display after telling the
player that a remembered-closed door was already open or a remembered-open
door was already closed. And in the cases where it did update the map to
reflect a change in door state, it didn't use up a turn. Now always update
the display and use up a turn when 'o' or 'c' reveals any new information.
