A couple changes dealing with overcrowded levels. So many monsters
are moving from the Plane of Water to the Astral Plane that the
latter can start out completely full.
Give monsters who trigger the endgame portals a 6/7 chance to not go
through ('home' elementals or any monster carrying the Amulet already
wouldn't go through). They should learn about magic portal trap in
the process and not voluntarily step on that afterward.
When the Wizard or other covetous monster tries to teleport next to
the hero and fails, he was being sent to limbo. There's no need for
that; he's already on the map and can just stay where he is. That
doesn't actually help with the endgame population issue, it just
fixes a couple of uses of mnearto().
I have significant changes for mnearto() and elemental_clog() that
also help with this but will test those more before committing.
when carrying things. The fuzzer toggled on 'perm_invent' and after
interrupting it I used ^I. Having 'perm_invent' enabled makes the
inventory code avoid having a totally empty inventory display (by
supplying "Not carrying anything" instead--in the menu rather than
via normal pline) so that interface code will see a change and know
that an update is needed. But to decide whether the menu was empty,
the inventory code was testing union 'any' field 'a_char' to check
whether some item had used the union (implying that something had
been passed to add_menu()), but wizidentify (^I) uses field 'a_obj'
instead. Apparently the a_char bits stayed 0 because the menu ended
up with "Not carrying anything" after a list of inventory items.
Switch to a separate variable to track whether anything has been put
into the menu instead of trying to rely on the union.
Unrelated but noticed when checking other "Not carrying anything"
instances, the #adjust command ends early when there's no inventory
but it was asking for a letter to adjust even when the only thing in
inventory was gold in '$' slot, which isn't allowed to be adjusted
away from that slot. Treat gold-only like no-invent.
Express the logic of various early returns more consistently.
clone_mon() wasn't handling mon->isminion correctly. I'm not sure
whether it is actually possible to clone a minion (maybe after
polymorphing it into a gremlin or blue jelly?). When it wasn't tame,
which is the case for every minion other than the guardian angel on
Astral, the emin structure wasn't being allocated for the clone but
its isminion flag was left set.
Also, clones inherited mon->mtrack[] so would unnecessarily avoid
moving onto spots the original had recently moved across.
Cloned pets are inheriting various pet-specific fields that they
probably should be starting with a clean slate on but I haven't made
any attempt to address that.
Observed on a text file with crlf endings on Linux, where the
so-called blank lines weren't being ignored as they should
have been, despite there being a line to remove \r from the
end.
A pointer was being pre-decremented before the check for a
matching whitespace character.
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.
Recent fuzzer tweak had an unintended side-effect: NUL character is
used to indicate a mouse click and we weren't setting up fake value
for one of those. Go back to avoiding NUL when obtaining a random
value for user's keystroke.
A recent change to make_slimed() overlooked a different recent change
in how mon->m_ap_type and youmonst.m_ap_type are referenced. In this
case it had no impact; fix on general principles.
Prevent the fuzzer from randomly toggling the 'silent' option. If
you use the default value of True then this eliminates most--but not
all--of the beeping that happens when it is running. I'm not sure
where the remaining beeps are coming from.
Modify the random keystroke selection to implement some bias towards
direction keys that I thought had already been there, plus a higher
chance to entering digits to initiate number responses.
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.
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.
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.
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#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.
Hero polymorphed into a vampire or v.lord can use #monster to switch
to vampire bat or fog cloud [or wolf for lord] but it was a one shot
polymorph. Remember when current form is a shape-shifted vampire and
allow #monster in shifted form to pick another shifted form or the
vampire form.
Genocide of the alternate shape forces back to base vampire. Genocide
of base vampire does too, then reverts to human (or dwarf, &c) as
vampires go away. Being killed while shafe-shifted reverts all the
way to human rather than to vampire. [Just realized: interaction
with Unchanging wasn't taken into consideration so hasn't been tested.]
Since 'youmonst' isn't saved and restored, I had to add a field to 'u'
to hold youmonst.cham during save/restore.
Tested with 3.6.2+ and seemed to be working (except saving while
shape-shifted restored as ordinary bat/cloud/wolf because new u.mcham
wasn't there to hold youmonst.cham yet). Builds with 3.7.0- but not
execution tested yet (I didn't want to clobber my current playground).
