Teleporting a monster only updated the map. Give a message
so blind players can get the same information.
Making a monster invisible gives the same message, if you
cannot detect invisible.
Several other places where monsters teleported themselves
now also give the same message.
I thought there were more places that checked for "it" and substituted
"someone" or "something". Perhaps there are and I'm just not finding
them now. Anyway, this extends x_monnam() and adds some_mon_nam() and
Some_Monnam() to do that during monster name formatting instead of
having various bits of code try fix it up after the fact. The fixups
could be fooled by monsters given the name "it" or "It"; x_monnam()
won't be.
Noticed when testing the "wall_angle: unknown" fix, if there is a
boulder rather than a door in the breach in a vault's walls at the
spot where the guard arrives, the guard would walk onto it, tell the
hero to drop any gold and follow, then move back. The boulder would
remain in the hero's way and couldn't be pushed because the guard was
in the boulder's way. Have the guard smash any such boulder(s) into
rocks when arriving (with no explanation for how that is accomplished,
just a message about seeing or hearing boulder(s) shatter). Later
when repairing the walls, delete any rocks or boulders at all vault
wall locations (even when no gap-to-wall repair is needed).
Fix the vault repair issue that could lead to "wall_angle: unknown"
warning. Unlike shop repair, the original wall info isn't available
so this recreates it. The extra 'flags' field added yesterday could
be eliminated but this leaves it in place.
Fixes#606
triggering an impossible warning about "wall_angle: unknown" due
to the known conflict between door state and wall info which both
overlay the flags field for map locations.
Reported and diagnosed by vultur-cadens: if a shop's wall was dug
open, followed by use of locking magic to plug the gap with a door,
and then unlocking that door, the D_CLOSED door flag was left as
invalid wall_info when shop damage was repaired. Map re-display
complained. Leaving the door locked or opening it after unlocking
did not result in any complaint because the values for those door
states do not conflict with wall angle values.
The problem was reproducible and is now fixed by adding an extra
field to the shop damage structure. A similar change has been
made to the vault guard's 'fake corridor' structure but I have no
test case for that so don't know whether it makes any difference.
At least it doesn't seem to have broken anything.
Existing save and bones files are invalidated by the fixes.
Fixes#606
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
When SCORE_ON_BOTL is enabled, you could tell how much gold is
inside a container with unknown contents by having 'showsore' On
and watching how much the score changed on the status line when
picking the container up.
For some reason the vault guard fake corridor code checked
if the hero was outside the corridor before removing monsters.
But the vault end of the corridor usually gets sealed off
even while you're still in the corridor. This left monsters
stuck in solid rock.
When GOLDOBJ was activated unconditionally, several texts started referencing
"money" instead of "gold".
As we don't have the intention to introduce a complex coin system with
different denominations, change it back and also some other places that
reference "money".
... when the guard is angry, and he's in the vault or in his corridor,
you're not in the vault nor in his corridor, and the level is full
so the guard cannot relocate.
Preserve temporary fake object's previous dknown value by storing it
as a flag value within the m_ap_type field of the posing monster, and
recalling it when it is needed.
This is intended to help eliminate observable differences in price display
between real objects and mimics posing as objects.
98% of this is just switching the code to utilize macro M_AP_TYPE(mon)
everywhere to ensure that the flag bits are stripped off when needed.
Do late message suppression in a different fashion. Also, there are
more messages than shk taking hero's possessions and guard taking
hero's gold that need to be suppressed if regular message delivery
is no longer possible: "do not pass Go", "you arise from the grave
as a foo", "the corridor disappears", "you are encased in the rock".
Those last two are from vault handling but take place in a convoluted
manner: paygd -> mongone -> grddead -> clear_fcorr.
Closing nethack's window sets 'program_state.stopprint' to inhibit
disclosure interaction, but shopkeeper claiming hero's stuff or vault
guard claiming hero's gold didn't honor that and just issued normal
pline messages. For win32, they got delivered in a popup even though
nethack's window had gone away.
Make those two end-of-game situations honor 'program_state.stopprint'.
[Fix not tested on win32...]
Fixes#101
If you tell the vault guard your name, drop carried gold, wait one
turn, then pick up the gold again, the guard will move a step away
during the wait. If you teleport away, the guard will seal vault
walls and then park himself on the one-square (so far) temporary
corridor adjacent to the vault wall. Periodically he'll say "Move
along!" and the hero will hear it, regardless of location on the
level. Unless you dig a corridor to rescue him, or one or more of
the vault's walls get breached again, he will never move.
The report emphasized that you could use this to steal the vault's
gold, but it relies on being able to teleport beyond the gaurd's
reach and if you can do that, you might as well do so before the
guard comes. The stranded guard, and him saying "Move along!" when
no longer leading hero out of the vault, are more significant bugs.
Bonus fix: if the game ends and the guard seals up the vault while
the hero is in a spot that gets fixed up (vault wall or temporary
corridor) don't give the "You are encased in the rock" message if
game end was due to death rather than quit.
Another one from nearly 7 years ago. Hero kicked embedded gold out
of a wall while following the guard away from the vault and got
"The guard calms down and picks up the gold."
and player thought it was odd because the guard was peaceful. It is
odd, but guards have an agitation state (0..7) when peaceful and it
is always non-zero when this event occurs. Suppress the "calms down"
part unless the agitation is close to making the guard turn hostile.
[Agitation is set to 5 after that event, so it isn't very calming.]
Also, the guard was picking up gold from underneath the hero while
two steps away. Move him adjacent (although it doesn't knock other
monsters out of the way if there's no room) prior to the message,
then back again after. That's how if works for gold that's not at
the guard's location and not at the hero's location, although that
case does knock another monster out of the way if one is on the gold.
Another 6.5 year old report. This one from Steven Melenchuk told
how to reproduce C343-23 which is still open on our 'known bugs'
page. (I've no idea whether the original bug report came through
the contact page, and if so, what its assigned number was.)
I didn't try to solve this one, I just confirmed that it could be
reproduced and took the fix from grunthack at github. He didn't
menion a fix at the time but implemented one before abandoing his
variant. (Others kept it going afterwards; fix was during his time.)
The overflow occurred when the guard couldn't figure out where to
move to next and just repeatedly 'moved' to his current location
until the maximum number of fake corridor spots was used up. The
fix detects not knowing where to go next and explicitly choosing a
new destination.
Original problem could be reproduced by teleporting into the vault,
digging out a wall and two spaces of stone in a straight line, then
going back into the vault to wait for a guard. When he shows up:
answer, drop gold, follow. If the guard's path walks through both
dug spaces, he will stop waiting for the hero. But hero is in
between the guard and the gap in the vault wall and can't advance;
guard has reached a persistent corridor so doesn't know where to go
next. Have hero wait for 125-ish more turns and then game panicks.
The code was 3.4.3 vintage so needed thorough reformatting, but not
any actual changes (unless I've overlooked something).
"Placing monster over another?" warning was triggered for vault guard
by an earlier change which made m_detach() stop removing monsters at
<0,*> from level.monsters[][]. So one guard would replace another at
<0,0> for however many guards were created, and memory for all but
the last one would be lost.
This involved a lot of flailing about and the patch includes various
things would could have been discarded. One or two extended monster
sanity checks are included, plus a couple of debugpline()'s for
tracking guard movement.
The logic required both x and y coordinates of the guard location and
the new location the guard wanted to move to be different. This is
obviously wrong, as the guard may move horizontally or vertically.
When using rloc and friends to move monsters, and the monster
happens to be a long worm, the tail may get randomly placed
in the same place where the long worm was removed from.
In the cases where we expect the location to really be free,
explicitly recheck the location for a monster after rloc.
Two different cases here: a) Vault guard did not move away monsters
except if they were standing on gold, and b) moving away monsters
on a completely filled level did not work
Most shop messages accurately identify the shopkeeper even when he
or she can't be seen, but some also include a pronoun reference that
ended up as "it" or "its" when not seen. Extend pronoun selection
so that visibility can be ignored: noit_mhe(mon), noit_mhim(mon),
and noit_mhis(mon). Note that despite being called noit_foo(),
those will still return "it" if mon is neuter.
"Accurately identify shopkeeper" is misleading if the hero is
hallucinating; a random shopkeeper name is used then. noit_foo()
yields the pronoun applicable to the actual shopkeeper and might
not match the gender of a hallucinatory name. That could be fixed
in a couple of ways (add shk_mhe()/shk_mhim()/shk_mhis() and either
pass them the randomly chosen name so that they can figure out the
appropriate gender, or just have them use a random gender whenever
hallucinating) but I don't think that's worth bothering with.
A bunch of shop messages needed noit_foo(); only a couple of those
have actually been tested. A bunch more were using shkname() at
the beginning of a sentence where Shknam() should be used instead.
(All the existing shk names are already capitalized so there's no
noticeable difference.)
The three places outside shk.c and vault.c which directly use
pronoun_gender() have been successfully tested.
Implement the suggestion that since teleporting away from the vault
while being confronted by the guard results in a shrill whistling
sound, the vault guard ought to have a tin whistle in his inventory.
I also added a check that he does have the whistle and to give an
alternate message if not, but after half a dozen tries to have a
squad of beefed up monkeys steal the whistle, they never accomplished
that. At least three times they took everything except the whistle
but I never succeeded in verifying the alternate message.
setmangry() and wakeup() were being used for multiple purposes. Add an
extra parameter to track which. This fixes several minor bugs (e.g.
whether monsters with no eyes were angered by (useless) gaze attacks
against them previously depended on the state of a UI option, and
the Minetown guards would be annoyed if you used a cursed scroll of
tame monster on a shopkeeper). It's also a prerequisite for the
Elbereth changes I'm working on.
