and receiving a random amulet instead of an "amulet of <foo>".
Although the failure to produce the 'right' amulet wasn't a regression
compared to earlier versions as the report indicated, supporting that
wish is straightforward.
Even though it isn't using verbalize() to make a specific statement,
don't let a demon ask the hero for a bribe when the hero is deaf.
Also, give alternate setup messages in a couple of places where a
divine voice is overriding deafness.
Recent commit 5d59b288c9 changed monster
zapping a fire horn at self to cure sliming to not use the wand-zap
feedback routine, but inadvertently did for zaps of wands of fire too.
Use the zap routine for wand and play-instrument routine for horn.
Most of the entries for '?' looked awful because curses was using
((terminal_width / 2) - 2) for the window width ('- 2' was to make
for for a border around the popup window, regardless of what the
'windowborder' option was set to). Splitting text that has been
manually formatted for 80 columns "worked" but looked bad when not
required.
Some of the help files are using 79 characters on a few lines,
producing wrapped text when displayed. Those would look better if
limited them to 78 or if curses can be modified to suppress the
window border when the entire display is being covered by a popup.
tty ignores map column #0 (0-based index), like the core, and draws
the map in screen columns 1 (1-based index) through 79, leaving screen
column 80 blank. curses was drawing all 80 map columns and since #0
was always unused, screen column 1 was blank and the map was shown in
2 through 80. Change curses to work like tty.
This was too easy; there may be problems lurking. One known issue: it
should be made smarter about when clipping/panning is necessary since
it thinks that a full 80 columns are needed but 79 suffice.
Like #annotate, #name monster, #name individual object, and #name
object type are places where it makes some sense to have an existing
name be the default for the new name, in case taking off from the end
and/or adding to the end is more convenient than retyping everything.
When there is an existing name used as default, clearing that default
and hitting <return> is not enough to remove the name, you still need
to 'assign a new name' of <space> to do that.
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
This time prompting isn't adversely affected.
This effectively reverts 1ad2415315
because it was interfering with prompts that spanned more than one
line (by inserting '--More-- + erase' between displaying of prompt and
getting input for the answer).
So we're back to the situation where autodescribe feedback when moving
the cursor will leave text on the second line if it generates text too
wide for one line. (^R redraws the screen correctly.)
For wizard mode 'monpolycontrol', the getlin() answer buffer for the
"Change <monster> @ <x,y> into what kind of monster?" prompt is also
used to format the coordinate portion of that prompt, so when
EDIT_GETLIN is enabled getlin() was inadvertently given "<x,y>" to use
as default response. Clear it after the prompt is formatted instead
of via an initializer. Also, shorten the prompt on the first try:
"Change <monster> @ <x,y> into what?", expanding to the old prompt if
retry is needed.
This also allows specifying 'chameleon' when <monster> is a chameleon,
'doppelganger' when it's a doppelganger, and 'sandestin' when it's one
of those (but not 'doppelganger' when it's a chameleon or sandestin,
and so forth), instead of blanket refusal to accept any non-vampire
shapechanger as the choice.
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
Add "Gateway to Moloch's Sanctum" to the vibrating square level if you
step on the square or detect/magic map it as a pseudo-trap, an extra
hint for players who manage to get that far but then don't know what
to do next. (I think I may also add a randomly placed floor engraving
along the lines of "For a good time, consult the Oracle of Delphi."
as a gag variant of "For a good time, call <name> at <phone number>."
Not very thematic for Gehennom but could conceivably nudge someone in
the right direction. But it could give away the level for experienced
players who haven't located the vibrating square yet.)
The annotation sticks until the one for "Moloch's Sanctum" gets added.
That happens when the temple on the sanctum level is entered or the
altar there has become mapped (in view or via magic mapping).
Could break existing 3.7.0- save files (but probably won't, since
at least two bits were available unless using an ancient 'Bitfield()
allocates whole bytes' configuration). That's the reason I didn't
put this into 3.6.2+.
The wizard mode runtime option 'wizweight' appends an object's weight
to its formatted description, but that was skipped for globs on the
assumption that it had already been included. But that inclusion only
happens in shops so most globs lacked weight feedback.
One of the claims in #H8849 was that a monster which zapped a wand
that the hero had fully identified made hero's knowledge of it revert
to "a wand". That doesn't happen; it had to have been a different
wand which hadn't been seen up close yet. But the hero should lose
track of known number of charges if a wand is zapped outside his/her
view. When implementing that I noticed that a monster playing a fire
horn to burn away slime was using the routine that gives wand
feedback. Add a separate, similar routine for magical horn feedback.
Half this diff is due to moving a naming support routine from mhitm.c
to do_name.c.
EDIT_GETLIN is more complicated on curses than on tty due to way that
long lines are handled....
Using ESC to get rid of the default response removed it from the
answer buffer but didn't erase back to the end of actual prompt,
making it look as if it was still there. Fixing that for a one-line
prompt+answer was needed and would have been easy but it also needs to
be prepared to go back to prior lines. Both the prompt and the answer
could conceivably span lines although in practice it will usually just
be one line or else prompt+answer combined spanning to a second line.
This hasn't been exhaustively tested been seems to be working correctly.
Fix a couple of glitches and add an enchancement. The monster
attributes structure left the 'hidden' field uninitialized unless user
specified "hidden". Mimics were being flagged with mon->mundetected
because they pass the is_hider() test but they 'hide' by taking on an
appearance rather than being unseen due to mundetected. hides_under()
monsters fail the is_hider() test, but can become mundetected if there
is at least one object present. Eels/other fish are neither is_hider()
nor hides_under() but can be mundetected at water locations. So alter
'hidden' handling to deal with these various circumstances.
Asking for 'hidden' for any type of creature will result in having its
location be highlighted if it can't be actively seen or detected. So
using '2000 ^G piranha' will fill up the Plane of Water "normally" but
'2000 ^G hidden piranha' will result in a ton of draw-glyph/delay/
draw-other-glyph/delay sequences and take a painfully long time. Moral
of the story: don't combine 'hidden' with a large count unless you
want to spend quite a while watching the level's fill pattern. Turning
off the 'sparkle' option will cut the flashing in half but still take
a long time. If you really need to fill a level with hidden creatures
and can't bear the flashing/highlighting, use blessed potion of monster
detection or #wizintrinsics to have extended detect. Then all created
monsters will be seen so none will trigger location highlighting.
If you create a 'stalker' or 'invisible stalker' or 'invisible <other-
mon>' its location won't be highlighted, but for 'hidden stalker' or
'hidden invisible stalker' or 'hidden invisible <other-mon>' it will
(provided you don't actually see it due to See_invisible or sensemon()).
Fixes#197Fixes#195
Add a call to nonl() to tell curses not to convert carriage return (^M)
to newline. Line input accepts both ^J and ^M as end of line/end of
input, but the core's command processing treats ^M as "unknown command"
(by default; someone could use the BIND option to assign some command
to that character). The end result is that accidentally pressing the
<return> or <enter> key (or Ctrl+M key combination) won't make the hero
run towards the bottom of the screen as if the user had typed ^J. The
curses docs also claim that it allows more optimization during screen
updating by making ^J work as plain linefeed rather than ^M^J newline.
The tty interface can achieve this (the 'do not convert ^M to ^J part',
not the 'more optimization' part) by issuing the command 'stty -icrnl'
(on Unix or sufficiently Unix-like system) prior to running nethack,
but that has no effect when using the curses interface (at least with
ncurses on OSX where I've tested it).
A better fix would be to look up the current terminal settings at
program startup and only call nonl() if -crnl was in effect so that
curses and tty would behave the same in this regard, but curses is
supposed to let us avoid those sorts of messy details....
Fixes#198
Watching a monster try to switch from a cursed weapon to some other
weapon (of any bless/curse state) reported that the old weapon was
welded to the monster's hand and wouldn't switch to the new one.
But watching a monster try to wield a cursed weapon didn't say that
it was becoming welded at the time. Report correctly pointed out
that the weld-to-hand check wouldn't work unless the weapon was
already flagged as wielded, and the code in question was deferring
wielding so that the message wouldn't include "(weapon in hand)" in
the formatted object description. There was also another problem:
it was erroneously testing the monster's old weapon (if any, after
unwielding it), instead of the new one being wielded.
Also, Sunsword starting to emit light when first wielded by a monster
only reported that it was shining if hero could see the monster.
Give an alternate message if hero sees the location instead. (Just
the monster's/Sunsword's location rather than any newly lit spot
within Sunsword's radius.)
Throwing or kicking a lit lamp, lit candle, or lit potion of oil
wasn't giving off any light as it travelled to its destination.
Now it does, and dungeon features, objects, or monsters that are
temporarily seen as it moves from square to square till appear on
the map. In the monster case, they go away as soon as the light
moves beyond range, but when it finishes moving the "remembered,
unseen monster" glyph will be drawn at their location. I think that
part has some room for improvement, but mapping temporarily seen
terrain features is the primary impetus for this change.
Also, any message delivery while the "lit missile" travelled still
showed its light around the hero. Noticeable for lamps or stacks
of sufficient candles if hero has no other light source.
This cannibalizes the monst->mburied bit for temporarily seeing a
monster. It has been present but unused for ages. I needed to
replace a couple of vision macros to make sure they didn't examine
it any more so that overloading for transient lighting doesn't
introduce any vision oddities. For version $NEXT, monst->mtemplit
can be given its own bit. It is only set during bhit() execution
and cleared by the time that returns, so has no effect on save files.
While testing, I noticed that I could completely fill the Water level
with air elementals.
Hero can't fly or levitate or water walk into/onto water locations
on Water level without drowning/crawling out the water, and monsters
shouldn't have been able to but could, then they were hit by drowning
since minliquid used different criteria than movement. But goodpos(),
used for teleport destination and new monster creation among other
things, consided water locations acceptable on that level for
non-aquadic creatures with Fly/Lev/Wwalk ability.
It explains why so many dragons and other 'nasty' monsters have been
ending up on the vanquished monsters list when hero uses level
teleport to go directly there from level 1. They've either been
getting created in water and then they drown when it's their turn to
move or moving into it to approach the hero and drowning (not sure
whether that case is immediate or on next move). There's no message
since hero doesn't see it, and air elementals didn't drown since thy
don't breathe.
placebc was triggering an impossible sometimes on the plane of
water
It turned out to be because movebubbles issued an
unplacebc(), but a downstream function called
placebc(), so when movebubbles() issued its own
placebc() there was a problem.
The downstream function that beat movebubbles to the placebc()
turned out to be unstuck(). There could be others.
If a corpse with a revive timer included obj->oextra->omonst for
remembering the original monster (I think all corpses do these days)
and makemon() failed to create a new monster when the timer expired,
the copy of the original wasn't freed. makemon() will fail if there
is no room for the monster.
Noticed when testing the set_bknown patch earlier: something updated
the persistent inventory window while scroll processing was in the
midst of traversing invent and it showed the scroll I'd just read
change from known blessed to bless/curse state not known. The scroll
should really be removed from inventory because player is told that it
has disappeared, but unlike charging (which does do that so that it is
gone when selecting an item to charge), remove curse isn't auto-IDed
and the code to ask the player to call an unIDed item something only
kicks in when it's still in inventory. Preventing the scroll in use
from having its bknown flag cleared should be good enough; it won't
have disappeared yet but at least it won't be visibly changing.
Carried containers could have their contents-known state and/or
lock-known state changed without persistent inventory window being
updated to show the new information.
This also changes the behavior when player has hero zap self with
wand of locking or wizard lock spell. If it doesn't trigger a
holding trap then the effect will hit inventory, similar to how
opening/knock operates (releasing hero from holding trap or hiting
inventory when that doesn't happen).
Changing an inventory item's bknown flag wasn't followed by a call to
update_inventory() in many circumstances, so information which should
have appeared wasn't showing up until some other event triggered an
update.
Fixes#196
If you didn't die from turning into green slime but then died because
green slimes had been genocided, the message given assumed that you
had just seen "OK, you don't die" from answering No to "Really die?".
Its wording didn't make sense if the reason you didn't die was an
amulet of life-saving. Give a different message for that case.
Also, if you survive turning into slime (via either method) and either
green slimes are still around or you answer No to "Really die?" when
they've been genocided, give a message after "You survived that attempt
on your life" pointing out that you have done so in green slime form.
Useful since prior to 3.6.2 you would have reverted to original form--
despite the Slimed countdown saying you had turned into green slime.
Even though a goodpos failure in mnearto() would return 0 to
the caller and trigger proper overcrowding handling for mtmp,
the 'othermon' would be left with its mx,my set to 0,0 under
that circumstance and then trigger a mon_sanity_check()
failure and accompanying impossible() message a short while
afterwards.
This also includes the addition of some flags that proved useful
for troubleshooting the mystery sanity_check failure and helping
to understand some of the code paths the struct monst data had
been through. They are only used for inspection when issues are
reported or when debugging, they don't presently control the
code flow. Their setting and use is done in an overloaded way
that should not intrude on the existing use of mspare1 for
MIGR_LEFTOVERS. mon->mstate is just a pseudonym for mon->mspare1
and does not alter save file content.
The key binding overhaul broke '&' reporting for movement commands.
This is somewhat clumsy but seems to be working as intended.
(M-0 with 'number_pad' set to 2 (or 4) appears to be broken. It's
supposed to be a synonym for 'I' but brings full inventory ('i')
for me. I have to set 'altmeta' On and type ESC followed by 0, but
that sequence does work to get M-0.)
