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.
Fixes#177
The monst struct has 'mintrinsics' field which attempts to handle
both mon->data->mresists and extrinsics supplied by worn armor, but
polymorph/shape-change was clobbering the extrinsics side of things.
Potentially fixing that by changing newcham() to use set_mon_data(...,1)
instead of (...,0) solved that but exposed two other bugs. Intrinsics
from the old form carried over to the new form along with extrinsics
from worn armor, and update_mon_intrinsics() for armor being destroyed
or dropped only worked as intended if the armor->owornmask was cleared
beforehand--some places were clearing it after, so extrinsics from worn
gear could persist even after that gear was gone.
So, fixing the set_mon_data() call in newcham() was a no go. This
fixes update_mon_intrinsics() and adopts the suggested code from
github pull request #177 to have mon->mintrinsics only handle worn
gear instead of trying to overload innate intrinsics with that. This
is a superset of that; the flag argument to set_mon_data() is gone
and mon->mintrinsics has been renamed mon->mextrinsics. (The routine
update_mon_intrinsics() ought to be renamed too, but I didn't do that.)
Polymorph control gives the player a chance to accept or reject a form
change due to lycanthropy, but if it occurs during combat or movement
the player might type 'y' before realizing that the prompt is pending.
Provide a paranoid_confirmation setting for 'Were-change' to allow a
player to require "yes" instead of 'y' for that.
The existing setting 'wand' is renamed to 'wand-break' and now requires
at least two letters in the config file options instead of just 1. The
spelling of its synonym is changed from 'breakwand' to 'break-wand';
it can be shorted to as few as 2 letters (same as before) but if more
than 5 are present, the new dash is required.
Both 'wand-break' and 'Were-change' are placed before 'pray' in the 'O'
menu for paranoid_confirmation so that all the "yes" vs 'y' settings
are grouped together.
Bonus fixes:
Reverting from were-critter form to human (due to timeout) did not give
a player with polymorph control the option of remaining in creature
form; now it does.
The 'O' command's menu would not show "wand" (now "wand-break") in the
current value of paranoid_confirmation. (A post 3.6.0 issue, so no
fixes entry included.)
The revised Guidebook.mn has been tested; Guidebook.tex has not.
Make it be cannabalism for a were<foo> to eat a <foo> corpse.
Let werejackals summon foxes and coyotes in addition to jackals,
and werewolves summon wargs in addition to wolves and winter wolves.
Duplicate of another recent report as far as drain resistance from
Excalibur/Stormbringer/Staff of Aesculapius not being shown by
enlightenment goes, but this one mentioned that it also wasn't being
shown for lycanthropy. Being inflicted by that does confers level-
drain resistance. were_change() wasn't calling set_uasmon() since
it isn't changing youmonst.data, but set_uasmon() is were intrinsics
conferred by creature form are set up. So call it when changing
were-form. Direct access to u.ulycn wasn't calling it either, so add
a new routine to assign the value to that instead doing so directly.
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!
Teleport_control is disabled while the hero is Stunned; do the same
with Polymorph_control. Also now disabled while unconscious, but that
is academic since random polymorphs and were-critter transformations are
postponed until multi is non-negative. I included it for completeness.
(Reverting to original form can occur while unconscious, but control is
not a factor in that situation. Teleporting handles being unconscious
differently but does negate control then.)
The fixes entry could just as easily have gone into the new features
section as into the bug fixes one. The teleport control part actually
belongs in fixes34.4 because it is present in the branch, but I didn't
feel like spreading this across two different files (and the current diff
references ``Unaware'' which doesn't exist in the branch so it isn't
trivial to include this patch there).
The prompt to a hero with lycanthropy and polymorph control about
whether to change into beast form had an extra space between the question
and the [yn] answer choices.
<email deleted> reported a long list
of inconsistencies and suggestions. This attempts to address the ones
about werecritters and vampires.
> Polymorphed player does not get werecreature changes. (intentional?)
> Player in were form does not turn into werehuman form, ever. (Previous
> bugged behavior was that player turned into a plain human)
> Player afflicted with a were cannot polymorph into werecreature or
> werehuman form.
The first guess is right; being polymorphed blocks lycanthropy state
changes. The second is not a bug either; hero is either a <werecritter>
when in beast form or a <role> when in human form, never human werecritter
monster. The last one feels more like a bug though; it happened because
all lycanthrope monster entries are marked NOPOLY. This patch extends
an earlier post-3.4.3 change to allow player with polymorph control to
explicitly specify werecritter when in role form or human werecritter when
in beast form to toggle shape. It also allows closely related monsters
to toggle from role to beast (ie, "giant rat" yields wererat).
> Vampire or Werecreature changing form may change sex.
Now the three semi-controlled changes--becoming a dragon due to armor,
toggling were form, and vampire into various critters--are prevented from
having the 10% chance of sex change kick in. For monsters, lycanthropy
didn't apply (sex never toggles) and vampire shifting is now covered but
turning into a dragon due to scales/mail remains susceptible to sex change.
Also, post-3.4.3 code made polymorphing into a vampire enable the
#monster command but neglected to tell the player.
Several polymorph tweaks, most dealing with specifying form under
polymorph control or for wizard #polyself:
1) allow "were<critter>" and "human were<critter>" for your type of
<critter> when you're inflicted with lycanthropy; now you'll toggle
shape rather than be told "you cannot polymorph into that".
2) allow your own role; now you'll become a new man (or whatever race)
rather than get "you can't".
3) allow "human" to force a new man (or whatever) regardless of race.
No change for human characters, but elves, dwarves, and such can now
use either their own race or "human". (They never become humans.)
4) for wizard #polyself only, override the 20% chance of becoming a new
man instead of taking on the selected form. (This implicitly prevents
the annoying "your new form isn't healthy enough to survive" death
since your experience level won't drop below 1.)
5) remove a redundant drowning check in polyself(); it's already handled
in polymon() and polyman(for newman()) via spoteffects().
This also gets rid of an old use of 0 as not-a-valid-monster (not
responisble for any bugs though since giant ants aren't lycanthropes).
>Hemmed in by one invisible wererat?
><Someone>: Should I feel hemmed in if I can see that a wererat summons
>zero rats? Can the invisible wererat hem me in all by itself? And
>even if it had summoned anything, wouldn't a different message had
>been clearer (for isntance, "Rats appear around you!"); after all,
>I could see *what* was hemming me in.
>I agree that the current messages (and even the ones aspired to by the
>comment) are non-ideal.
<Someone>'s suggested set-up:
Seen summoner, seen help : "The wererat summons help!"
Seen summoner, unseen help: "The wererat summons help! You feel hemmed in."
Seen summoner, no help: "The wererat summons help! But none comes."
Unseen summoner, seen help: "(A rat appears|Rats appear) from
nowhere!"
Unseen summoner, unseen help: "You feel hemmed in."
Unseen summoner, no help: No message.
+ Separate the two uses of flags.soundok.
+ Player-settable option is now called "acoustics".
+ Deafness is now handled as a full-fledged attribute.
+ Check for deafness in You_hear(), rather than caller.
+ Check for deafness in caller, rather than verbalize(),
because gods can speak to characters in spite of deafness.
+ Since changes are being made to prop.h, reorder it to the
same order as youprop.h and enlightenment.
There are still some extraneous checks and missing checks
for deafness, which will be followed up in a future patch.
Because of the size of this patch and its savefile incompatibilities,
it is only being applied to the trunk code. Portions of this patch
were written by Michael Allison.
Change the monster constants to match the current position of the switch
statement. Also test canseemon(), since the message isn't needed if you
see the change. I didn't make any other change to the message frequency.
If it's too frequent, then perhaps the changes themselves are too frequent.
Forwarded from the newsgroup: when a monster gets hit by wand or
spell of polymorph, any armor that fell off was protected from being
hit by that same zap, but a dropped weapon wasn't. Nor was the whole
dropped inventory in the case where the monster is killed by system
shock rather than transformed. Protect its entire inventory.
