Wand of make invisible doesn't make you permanently invisible,
just for a short duration. Potion of invisibility makes you
invisible for much longer period, or if blessed, has a small
chance of giving permanent invisibility.
This makes the wand actually useful, and improves the spell
too.
Skeletons are extremely rare, and not generated at random,
and bone devils are basically just a speed bump when they appear.
Make both more interesting.
Idea by copperwater <aosdict@gmail.com>
Reported 11 years ago, the level definition for the Samurai quest
home level specifies a throne room and entering it gives the "opulent
throne room" message, but there isn't any throne.
Initially I was going to add a throne but decided that its lack is
probably intentional. The throne room designation is used to give
periodic atomspheric messages. That's my guess anyway.
Alter the room entry message there to omit "throne" from "you enter
an opulent throne room". Add a no-throne comment to Sam-strt level
definition.
While in there, make Lord Sato's katana and splint mail explicitly
rustproof and either blessed or uncursed. (The mail was already
implicitly rustproof because splint mail created on the Sam quest
home level always is, like for a Samurai's initial inventory.)
This was causing a really annoying to track down bug where
the fuzzer threw the attached iron ball and it could end up
anywhere on the level, emitting a sanity check error.
Clipping mode was not activated when a comfortably-sized game window was
resized horizontally to become too narrow to display the entire map,
causing various display errors and bugs if the window was resized like
that. I think the horizontal resize check was removed by mistake in
d1dade164e.
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.
Pull request from entrez: implement a couple of features that were
mentioned in new comments in the 'fixes entry' commit when PR #1093
was adopted.
1) throwing/kicking an unIDed fake amulet of Yendor at the quest
leader will identify it rather than be considered an attack;
2) throwing/kicking the Bell of Opening, Candelabrum of Invocation,
or Book of the Dead at the leader will ID the item as in #1093,
but if the invocation has already been performed, the leader will
keep the item rather than return it.
Closes#1096
The other suggestion from Pat about potential extensions to bda0b3b. I
think it's interesting from a story perspective, and hopefully nobody
will run into this by mistake when they hoped to use the Candelabra as a
light source later! The specific language used by the leader could be
changed if someone has a better idea (as could the code itself, for that
matter).
If the hero throws an unidentified fake Amulet of Yendor at the quest
leader, the leader will identify it and toss it back, similar to the
behavior for the real Amulet.
This was one of Pat's suggestions for continuing in the same key as
bda0b3b; I think this makes a lot of sense, especially now that people
may be encouraged to throw things called "Amulet of Yendor" at the quest
leader. Arguable about whether a _known_ fake Amulet should still anger
the leader and quest helpers; as I have it in this commit, it will, but
I'm somewhat ambivalent about what makes more sense.
While experimenting with a potential status change I managed to get
a corrupted message in paniclog:
|status_sanity_check failed on tty_status[NOW][Jan].
where "Jan" was intended to be a "BL_" name.
Make tty's status_sanity_check() be a bit more robust. This fix
shouldn't have any effect on the stable code.
If there were outdated savefiles encountered during
startup, each individual one was getting a wait_synch
that required a <return> even though a message window
wasn't being used at that point.
Allow suppression of the individual per-file wait_synch()
calls on Windows, so that a single one can be done once
the selectsave processing is overwith.
This was a little messy because an indicator had to flow
down through validate(), uptodate(), etc.
There shouldn't be any change in how things behave on
any non-Windows platforms.
Reported by a hardfought user, a ceiling_hider monster hid on the
Astral level, triggering a sanity check warning that gets repeated
each move until the hider comes out of hiding. Normally sanity_check
can only be set in wizard mode, but hardfought must force it on for
to-be-3.7.
I was able to reproduce it before this fix and unable to do so
afterward, but there is a random factor involved hence no guarantees.
I think that lack of ceiling for Astral is recent, but this could
have happened on other levels which lack a ceiling. I didn't try to
figure out whether it might happen with 3.6.x, just put the fixes
entry in the "exposed by git" (found in code not yet released, that
is) section.
Pull request from entrez: if hero throws (or kicks) an invocation
item or the Amulet at the quest leader, identify it and give it back
instead of treating the throw (or kicked item) as an attack.
In addition to the fixes entry I've made several tweaks to related
code, mostly to refer to the leader as "Someone" rather than "It" if
unseen.
Closes#1093
