Reported by entrez: when fruit name is given the name of an artifact
that doesn't use "the" at the start of its name, messages about the
artifact could be altered. Example was fruit=Excalibur causing usual
|You are blased by Excalibur's power!
to unintentionally change to
|You are blased by the Excalibur's power!
because of a false match during special handling for named fruit in
function the().
This fixes that, and also changes basic inventory formatting. Former
|f - an Excalibur
will now be
|f - Excalibur
for a fruit that has been assigned that name. When sort pack in On,
as it is by default, that will be listed under Comestibles rather than
under Weapons so really shouldn't fool anyone. And
|f - 2 Excaliburs
also breaks the illusion.
This formatting change only affects named fruits. User assigned names
for object types or for individual objects behave the same as before.
Function the() wasn't supposed to be used for monsters because many
of the ones with capitalized names confuse it, but over time multiple
instances of the(mon_nam()) have crept into the code. Instead of
ripping those out, modify the() to handle that situation better.
Pull request #636 by entrez dealt with this with one extra line of
code, but could end up scanning all the names in mons[] repeatedly
if the("Capitalized string") gets called a lot. This uses a similar
one line fix but calls a whole new routine that scans through mons[]
once collecting all the relevant special case names. As a bonus,
it does the same for hallucinatory monster names which name_to_mon()
couldn't handle.
Fixes#626
Globs never rotted away but did become tainted after a relatively
short while, which seemed like a contradiction. Change them to never
be tainted but shrink by 1 unit of weight approximately every 25
turns. An ordinary glob (one that hasn't combined with any others)
starts out weighing 20 units, so it takes about 500 turns to vanish.
That's roughly twice as long as a corpse takes to rot away.
Shrinking globs give feedback when in hero's invent or in a container
in hero's inventory, but rarely (when going from an exact multiple
of 20 weight units; that is, from integral number of N globs to
N-1 + 19/20, or if weight reduction triggers an encumbrance change).
When a glob goes away completely, there is feedback for those two
circumstances and also for seeing the glob vanish from the floor.
I haven't touched how much nutrition eating a glob confers. I have
changed formatting of glob names to use "small", "medium", "large",
"very large" instead of "small", [no adjective], "large", &c. You
still need to have at least five globs coalesced together for the
adjective to become "medium", same amount as before.
I don't think EDITLEVEL needs to be modified but have incremented it
anyway to play things safe.
Guard against any other places besides minimal_xname() that set up a
fake object without being aware that for boulders the corpsenm field
should be 0 rather than NON_PM. If that field is unexpectedly -1,
xname() will format it as ordinary "boulder" rather than producing
special "next boulder". An explict value of 1 is now required for
the latter.
simpleonames() calls minimal_xname() which was setting up a dummy
object and making its corpsenm field be NON_PM. For a boulder, that
yielded "next boulder" instead of the intended "boulder".
When you push a pile of boulders, describe the second and remainder
as "the next boulder" rather than just "the boulder". Matters most
when pushing into water or lava and you keep on pushing when the
first one or more sink into the pool or plug it, but also matters
for an ordinary push where the top-most one moves successfully and
then blocks the continuation attempt to push the second one. It was
somewhat confusing when all the messages said "the boulder" whether
they were referring to the same boulder or different ones.
Multiple pushes on the same move has always been a bit odd, but this
doesn't change that, just the feedback it generates.
Some code from about a month back changed xname() and doname() to
only use a single 'obuf[]'. That was to make sure that perm_invent
update also used at most one obuf. They use some slightly convoluted
code when they called other routines which returned an obuf because
only the most recently allocated one can be explicitly released for
re-use. That works, so I did the same for simpleonames() and
thesimpleoname() and for some reason neglected the convolution for
simpleonames().
For the case where plural was needed, it needs two obufs and tried
to release the first, which is a no-op. So if it was used in a loop
like display_pickinv() uses doname(), it could have cycled through
all the obufs and clobbered one a caller was expecting to remember.
I'm not aware of any instances of this being an actual problem, just
happened to notice that simpleonames() was different from other
similar routines.
Reported and diagnosed by entrez:
"The <mon> yanks <two-handed weapon> from your corpses!"
It became unwielded and that triggered a perm_invent update and
such updates reformat entire inventory, so if that contains a dozen
or more items it will use all the obuf[] static buffers as least
once. In this case, the bullwhip code had plural of "hand" in one
of those buffers and by the time it delivered the message which
used that, the value had been clobbered.
As the diagnosis mentioned, it can be tricky to reproduce since
either &obuf[0] or &obuf[PREFIX] might be used and if the value
being clobbered didn't overlap, the effect wasn't noticeable.
Instead of fixing the bullwhip message, this changes inventory
display so that it should no longer churn through all the buffers.
It also adds a fixes entry for #K3401, which was already fixed for
3.7 but I hadn't been able to reproduce it for 3.6.x (which I now
blame on the PREFIX trickiness).
Add two new monsters and two new objects:
gold dragon
baby gold dragon
gold dragon scale mail
set of gold dragon scales
A couple of variants seem to have added these already, but this came
off my ancient list of monsters to add and was done from scratch.
It's a clone of silver dragon, but instead of having reflection and
breathing cold, a gold dragon emits light and breathes fire; because
of the latter it can be seen with infravision like a red dragon.
Adult gold dragons are lawful as in the AD&D Monster Manual rather
than chaotic as the wiki pages show for the variant versions.
Worn gold dragon scales operate similar to wielded Sunsword: when
blessed, radius is 3 (same as a lamp), if uncursed, radius is 2, and
if cursed, radius is 1 (but functions as 2 when worn by the hero,
otherwise there would be no tangible effect). Gold dragon scale mail
gets an extra +1, making blessed gold DSM have a bigger radius than
lamps. Embedded scales have radius 1 regardless of BUC state; light
for that case comes from the gold dragon monster form the hero is in.
When not worn, gold scales and scale-mail don't emit any light.
The tiles use a mix of yellow (for gold) and red. The two object
tiles seem reasonable variations of the corresponding silver dragon
ones. The two monster tiles definitely need work since the silver
ones were mostly cyan and changing that to red did not produce very
good result; subsequent attempt at a mixture was haphazard at best.
Add "ukulele" to the exceptions that yield "a u<something>" in case
someone names their fruit that. Add the shortened form "uke" too.
While in there, generalize "one" handling to accept "one", "one<space>
<anything>" and "one<underscore><anything>" as exceptions in addition
to existing "one<dash><anything>", and "eu<anything>" to replace
existing "eucalyptus".
Fixes#552
Functionally similar to reading a T-shirt or apron, but rather than
actual text printed on the shirt being displayed, the design of the
Hawaiian shirt is described: for example, "hula dancers on an orange
background" or "tropical fish on an abstract background". Much like
T-shirts have their text included in the game-end inventory list ('a
blessed +2 T-shirt with text "foo"'), Hawaiian shirts now have a brief
description of their design appended to their item name under the same
circumstances.
Because 'reading' a Hawaiian shirt doesn't actually involve reading
text, using the 'r' command in this way doesn't break illiterate
conduct.
Changes in wish parsing included with figurine gender implementation
3 or so weeks ago accidentally broke asking for "large box" and
possibly other stuff.
Re-do "paperback book" handling to accept "paperback" and "paperback
book" but to reject previously accepted "paperback spellbook" when
wishing for a novel by description.
Something I noticed recently: a wish request for "paperback book"
yielded "Nothing fitting that description exists in the game."
Asking for "paperback spellbook" worked though.
I'm not sure whether this is the best way to handle this particular
exception but wishing for "paperback book" now works.
Use (obj->spe & CORPSTAT_GENDER) for figurines as well as for
statues and corpses.
Support wishing for
"{female,male,neuter} {corpse,statue,figurine} [of <monster>]".
and
"{female,male,neuter} <monster> {corpse,statue,figurine}".
Also
"{corpse,statue,figurine} of {female,male,neuter} <monster>"
where the qualifier might be in the middle instead of a prefix.
Revive some code from 5 or so years ago that's been sitting in a
defunct local git branch. There are a couple of references to
figurines having gender; the old, unfinished code did already have
support for that, the current code doesn't. It probably won't take
much effort to add it in but I want to get this first part out of
the way.
Replace some of the
pmname(mon->data, Mgender[mon]) calls with simpler
mon_pmname(mon) and some
pmname(&mons[statue->corpsenm],
(statue->spe & CORPSTAT_GENDER) == ... ? ... : ...) with simpler
obj_pmname(obj). There are other instances of them which haven't
been changed but could be.
Dead monsters that had traits saved with the corpse would revive as
the same gender, but ordinary corpses revived with random gender so
could be different from before they got killed.
Since corpses of monsters lacked gender, those for monsters with
gender-specific names were described by the neuter name.
This is a fairly big change for a fairly minor problem and needs a
lot more testing.
Fixes#531
that has no nutritional value. Prevent applying the partly eaten
attribute to wished for food if the full nutrition isn't at least 2.
The problem case was 0 nutrition wraith corpse, yielding "partly
eaten food (1) more nutritious than untouched food (0)" when setting
the corpse's weight. That one was possible in 3.6.x, unlike corpse
that was actually partly eaten and then revived as a zombie (which
was just fixed for triggering the same warning).
Wishing really ought to ignore "partly eaten" for anything that is
normally eaten in one bite but I'm not sure how to handle that.
Fixes#504
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).
