It was possible to wish for a secret door, if done at a wall or
door location, but not for a regular door. Add that. (Dig
followed by locking magic possibly followed by open or by kick
could cover most of the details without wish support, but there
wasn't any way to force a closed or locked door to be trapped.)
The wish request can include "trapped" (or "untrapped", the
default) and/or one of the 5 door states: "locked", "closed",
"open", "broken", or "doorless" (default is "closed"). If more
than one state is specified, the last one in the wish text
overrides others. If trapped is specified with open or broken or
doorless, it will be ignored.
Allow "looted" when wishing for a fountain, sink, throne, or tree.
For the ones with multiple loot tracking bits, it sets them all.
Explicitly reject a wish for a wall rather than claiming nothing
of that description exists.
Formatting: wrap various wide lines.
"You hear a [BCDG] note squeak in the distance" is ok, but
"you hear a [AEF] note squeak in the distance" isn't.
Squeaky board notes already had correct a/an handling but that
particular message explicitly suppressed it.
Prevent a wish request of "death wand" (as alternate spelling
for "wand of death") from matching "Death" monster and yielding
a random wand.
"death finger" and "death finger spellbook" produce a "spellbook
of finger of death" even without a similar fix.
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.
Cap overall AC at -99 instead of -128. Put the same limit of 99
on enchantment and charge count of individual objects.
^X now reports if/when AC has reached its limit since players
could see that reaching that limit and then enchanting worn items
will change the worn items but not the total. (Same thing would
have happened with -128, just without any explanation and less
likely to accomplish.)
Won't affect normal play for any reasonable definition of normal.
Adopt the patch to show the writing on any alchemy smocks in
hero's inventory during end of game disclosure.
I also added one more saying among the choices for alchemy
smock/apron. It's based on a T-shirt descibed in a movie.
(I remember the description of the text but I don't remember
noticing anybody wearing the T-shirt that lead to that.)
Since so many of the smock quotes are about cooking, it seems
better to add it as an alchemy quote instead of just another
T-shirt where there'd be no context to explain it.
Closes#417
Move the core's global restoring flag (not the same as main()'s
local resuming flag) to a more logical place. Add a saving flag
in the process, but it isn't being set or cleared anywhere yet.
(Once in use it will probably fix the exception during save that
was just reported, but before that it would be useful to figure
out what specifically caused the event.)
The program_state struct really ought to be standalone rather
than part of struct g but I haven't made that change.
Removing an unused variable for wishing and some reformatting
that whent along with it got mixed in. Removes some trailing
whitespace in sfstruct.c too.
Only lightly tested...
Adopt the suggestion that candy bar stacks which get split should
keep the same wrapper text for both halves of the stack. The patch
stuck with using obj->o_id to manage the wrapper which prior to the
patch wasn't a factor in merging and splitting. Switch to obj->spe
instead, comparable to tin varities, so mergability is already
taken care of.
End of game disclosure tacks on T-shirt text to formatted items.
Do the same for candy bar wrappers.
I tried wishing for "splashes of venom" but was told that no such
thing exists even though "splashs of venom" and "2 splash of venom"
both work to produce "2 splashes of venom". After the spurious
failure, retrying with EDIT_GETLIN enabled showed that "splashes"
had been singularized to "splashe" so fix that.
"2 splashes of venom" IDed to "2 uncursed blinding venoms" because
the base name omits "splash of" prefix. And due to that, explicitly
wishing for "splash of {acid,blinding} venom" didn't work either.
Change the names to include the prefix, and add a hack to makedefs
to keep generating the old macro names without the prefix. (Wishing
for "{acid,blinding} venom" still works due to post-3.6.6 changes
to " of " matching.)
Allow "esp helmet" to find "helm of telepathy" and "power gloves"
to find "gauntlets of power". Plus add a few item names used in
other games that have a close enough match in nethack.
We haven't added any new objects or monsters in a really long time.
This adds two new useful amulets, putting more pressure on the
decision over which type of amulet to wear.
amulet of flying: idea from slash'em, implemented from scratch.
Should be self-explanatory. Polymorphing into a form capable of
eating amulets and then eating one does not confer intrinsic
flight. (I've no idea how slash'em behaves is in that regard.)
amulet of guarding: adds +2 AC, which is fairly negligible, also
+2 MC, which is not. Initially called amulet of protection but MC
of 2 is referred to as 'guarded' by enlightenment so I changed it.
(By that reasoning, rings of protection ought to be called rings of
warding; oh, well.) Successfully eating one confers +2 AC without
any MC benefit. When wearing one of these, rings of protection
only confer AC, their +1 MC gets superseded rather than combined.
Monsters will wear an amulet of guarding and gain both the AC and
MC benefit, but if not cursed and they acquire one of life-saving or
reflection, they'll swap. They won't wear an amulet of flying.
I cloned two extra copies of the tile for one of the existing amulets
and ran sys/share/objects.txt through renumtiles.pl. The result
appears to be ok but on X11 the tiles map ends up looking psychedelic
so something beyond the tile art itself needs to be fixed here.
Wishing allowed "royal jelly" to match "lump of royal jelly" as a
special case, but not "wolfsbane" to match "sprig of wolfsbane" or
"tricks" to match "bag of tricks". Handle that sort of match in a
more general way.
While in there, add a minor glob bit: instead of giving a random
corpse (because monster is flagged as no-corpse) if someone wishes
for "gray ooze corpse" give "glob of gray ooze".
Fixes#325
"were{rat,jackal,wolf}" each occur twice in mons[], once for the
beast form and second time among '@' for the human form. Wishing
for werecreature corpse or tin always matches the first entry so
yields the beast form, but all their beast forms are flagged as
no-corpse so the wish would fallback to a corpse with random monster
type. Wishing for werecreature figurine worked but always produced
one that created its beast form if/when activated.
This fix allows specifying "human werecreature" to match the second
entry. It's optional for corpse and tin; the wish code will now
switch to that implicitly if it gets a no-corpse were-form for
those. It has to be specified explicitly to get a figurine that
will activate as the human form. It works for ^G too.
Fixes#326
name_to_mon() has a bunch of alternate monster names, such as
"gray-elf" to match "grey-elf" and "ki rin" to match "ki-rin". Those
worked as intended when they occurred at the end of a wish, but only
worked in the middle if their length was the same or one character
less than the canonical name in mons[].mname.
djinni figurine -> h - a figurine of a djinni
genie figurine -> i - a figurine of a djinni
figurine of mumak -> j - a figurine of a mumak
mumak figurine -> k - a figurine of a mumak
figurine of mumakil -> l - a figurine of a mumak
mumakil figurine -> nothing fitting that description exists
(The one-less case worked because its following space ended up being
implicitly removed when skipping ahead by the length of mons[].mname;
subsequent explicit removal didn't find a space so was a no-op.)
The bases[] array allows finding the index of the first object in
a particular class. Extend it so that bases[class + 1] - 1 is a
reliable way to find the last object in any class. The array had
to be extended by one so that the last class has a [class+1] entry
available, and object initialization now makes sure that classes
within objects[] are in ascending order so that [class+1] always
holds a higher index than [class].
Changing terrain type without moving wasn't registering as moving to
different terrain. A Passes_walls hero who has levitation blocked
while moving through solid rock can wish for furniture. Levitation
remained blocked unless hero moved off that spot and then back on.
Doesn't affect normal play. Changing terrain by digging already
deals with similar situation; not sure whether there are any other
situations that might need to handle it.
Royal jelly applied on an egg will change a killer bee egg to
a queen bee egg. Cursed jelly will kill the egg, uncursed and blessed
will revive it. Blessed jelly will also make the creature think
you're the parent.
Original patch was by Kenneth Call
Try a lot harder to keep terrain/level flags in a sane state. They're
overloaded so it's not simple.
Creating a fountain or sink incremented the corresponding counter (for
controlling ambient sounds) but removing one by wishing for something
else in its place didn't decrement.
Allow wish for "disturbed grave" to create a grave with the 'disturbed'
flag set, similar to existing "magic fountain" and 'blessedftn' flag.
(I didn't add "looted throne", "looted tree", and several other things
that use the 'looted' overload of 'rm.flags'.)
Automate block_point (tree, cloud, secret corridor, or secret door in
open doorway) and add unblock_point (use Pass_wall to move into wall
or tree or stone, or just walk onto a cloud, then make iron bars or
almost any other wishable terrain to replace the blocking feature).
Move 'implicit_uncursed' and 'mention_walls' from iflags to flags to
make their current setting persist across save/restore. Invalidates
existing save files.
Guard against potential bad arguments: first index greaer than last.
Return STRANGE_OBJECT instead of hardcoded 0 if it ever fails (which
should be impossible with good arguments).
Make wish for "amulet of yendor" be the same as "real amulet of yendor"
instead of preserving the 3.6.x behavior of having a 50% chance of it
yielding "fake amulet of yendor".
Both the "real" and "fake" prefixes are still accepted, but "real" has
become a no-op:
!real and fake, real and fake => fake
real and !fake, !real and !fake => real
so fake vs !fake always decides the result.
globwt() didn't check for wizmode, so unpaid globs would be shown with weight
information even for normal player.
Eliminated globwt() completely and consolidated the output of aum in one place
as we don't really care about the ordering of debug info in wizmode.
Recent object formatting changes for wielded weapon put some pline
arguments in the wrong order.
a - aklys (weapontethered in hand)
or worse, when dual-wielding
a - aklys (wieldedtethered in right hand)
Change back to
a - aklys (tethered weapon in hand)
or
a - aklys (tethered weapon in right hand)
I considered (tethered weapon wielded in right hand) for the two-
weapon case, but I think that's too verbose.
Wizard mode wishing for "Amulet of Yendor" has a 50% chance of
yielding a cheap plastic imitation. Allow asking for "real Amulet
of Yendor" and "fake Amulet of Yendor" to provide precise control.
Asking for "real Amulet of Yendor" in normal play will be accepted
but then overridden with the fake amulet as usual.
Without the prefix, there's still a 50:50 chance for either amulet.
"real fake amulet of yendor" and "fake real amulet of yendor" both
yield a fake one.
When handling "amulet of yendor", any of "cheap", "plastic",
"imitation", "cheap plastic", "cheap imitation", and "plastic
imitation" are now recognized to mean "cheap plastic imitation".
Unlike prefixes such as "blessed rustproof" vs "rustproof blessed",
these two-word ones (or the three-word whole thing) need to be in
specific order and after the general prefixes. Also, any of those
force "fake" even if an explicit "real" prefix came before them.
Allow wishing for secret doors and secret corridors. It's a bit
more strict about where the wish is performed than wishing for
furniture. Implemented in order to test drum of earthquake effects.
I spent a lot of time figuring out SDOOR details that somebody
already knew at some point but evidently didn't document--you can't
specify D_CLOSED for them or the display code will issue impossible
warnings about wall mode angles.
Don't allow dual-wielding if either wielded or alternate weapon
(or both) is a launcher: bow, crossbow, or sling. (I thought that
this had been addressed ages ago.)
Refine the "can't twoweapon" feedback. The message for having
either or both hands empty is the same, but sentence construction
is different. The not-a-weapon feedback is slightly different, now
mentioning whether it's the wielded or alternate weapon which isn't
allowed. The case where neither are acceptable still just reports
uwep; mentioning both it and uswapwep would be too verbose.
Make more things be described as "(wielded)" instead of "(weapon in
hand)". It was just stacks with quantity more than 1. That's now
joined by ammo and missiles (any stack size, but in reality just 1
since greater was already being caught here) and any quantity of
non-weapon, non-weptool. It's overridden if dual-wielding so that
right/left stay matched.
When dual-wielding, list primary as "(wielded in right hand)" and
secondary as "(wielded in left hand)" instead of "(weapon in hand)"
and "(wielded in other hand)". The vaguer wording was better for
bows since they're held in the off hand but now that they can't be
dual-wielded that doesn't matter. (Single-wielding a bow is still
"(weapon in hand)".)
When not dual-wielding, the item in the alternate weapon slot is
still described as "(alternate weapon; not wielded)" even if it's
not actually a weapon. I couldn't think of better phrasing.
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
Add hallucinatory trap names
This adds many funny, realistic, and nonsensical traps to the game, to
be shown when the player is hallucinating.
Architecturally, the biggest change is merging the what_trap macro and
the "defsyms[trap_to_defsym(ttyp)].explanation" pattern into a single
function "trapname", which returns the name of the trap, handling the
hallucination case. There is also a second parameter used for overriding
hallucination in the occasional cases where the actual trap name should
always be returned.
In addition, the what_trap and random_trap macros are now obsolete and
not used anywhere, so they are removed.
reinstate anti-rng abuse bit on hallucination
updates to hallucinatory trap names and fixes37.0 entry
Poly'd hero hiding on the ceiling was told "you can't go down here"
if using '>' at a spot that didn't have down stairs, trap door, hole,
or pit. Let '>' bring a ceiling hider out of hiding; lurker above
resumes flying, piercer falls to floor or whatever is underneath it.
Fix some issues noticed when experimenting with ceiling hiders.
They're all blind (at least without the monks' Eyes) and some of
the behavior while blind seemed to be incorrect (though some that
I thought was wrong turned out to be ok; feel_newsym() won't update
the map if the hero can't reach the floor). Fixing that made me
notice that some terrain side-effects (being underwater or stuck in
lava) weren't getting disabled when the underlying terrain wasn't
the corresponding type anymore.
Handle recently changed armoroff() differently. There should be no
change in behavior.
boots_simple_name(), shield_simple_name(), and shirt_simple_name()
are for no-delay armor types so won't be called by armoroff(). But
they'll undoubtedly get some use in the future.
Developed for 3.6 but deferred to 3.7. Most of the testing was with
the earlier incarnation.
Report was that pronouns were accurate for the underlying monsters
when hallucination was describing something random, and also that the
gender prefix flag from bogusmon.txt wasn't being used. The latter
is still the case, but pronouns are now chosen at random while under
the influence of hallucination. One of the choices is plural and an
attempt is made to make the monster name and verb fit that usage.
|The homunculus picks up a wand of speed monster.
|The large cats zap themselves with a wand of speed monster!
|The blue dragon is suddenly moving faster.
There is no attempt to match gender for the singular cases; you might
get
|The succubus zaps himself [...]
or
|The incubus zaps herself [...]
