Pull request by mkuoppal: some objects which use the corpsenm field
to access the mons[] array can have a corpsenm value of NON_PM (-1)
and weren't avoiding array access in those cases.
In addition to a fixes entry for it, this makes some revisions to the
commited code, handling a few of the cases differently.
Closes#1175
TIN or EGG can have the corpsenm not assigned into a
proper monster and instead have an value of -1.
Take this into account in assigning the monster (fptr)
pointer to only point into >= LOW_PM monste entries.
Some players of 3.6 recently noticed that sometimes, mimics in shops
seemed to have moved around even before the player had entered the shop
or done anything to uncloak them. I found that this was because
finish_meating was being called for all non-eating monsters when
restoring a level (monsters that weren't eating anything would have
meating == 0 so always pass the 'imv > meating' check). This would
uncloak mimics -- but not all the time, because the 'mappearance != 0'
test meant mimics disguised as strange objects weren't uncloaked. I
think that was meant to be an additional check to confirm the monster
really did have a disguise, but in reality it meant that M_AP_OBJECT
"strange object", M_AP_MONSTER "giant ant", etc disguises wouldn't be
removed by finish_meating.
As it turns out, this was mostly fixed by coincidence in 221e4a7, which
fixed the "exclude actual mimics" check in finish_meating. So at this
point in 3.7 it's largely a latent bug, but it still had the potential
to improperly uncloak non-mimics who can disguise themselves (like the
Wizard of Yendor, maybe?), and could cause other problems if
finish_meating were updated to have additional effects, or if some
monster types were made to disguise themselves as a strange object when
eating a mimic.
When a pet ate a mimic corpse and started mimicking a monster,
and the user then used #wizmakemap, the sanity checker complained
about "non-mimic posing as foo" - the code was clearing the
pet eating counter, but didn't clear the appearance.
Simplify suppression of highlighting for menu header lines during end
of game disclosure. Didn't actually affect as many things as I was
expecting.
Plus a bit left out of the optfn_dogname() parsing commit.
From a reddit thread: a tame mind flayer ate Medusa's corpse and was
turned to stone. Pets won't eat cockatrice corpses unless stoning
resistant but would eat Medusa's corpse if merely poison resistant.
Mind flayers aren't normally poison resistant but could be if wearing
green dragon scales/mail.
Augment the touch_petrifies() test when classifying food for pets.
Player reported that a cat which was asleep in a treasure zoo would
catch and eat thrown food, becoming tamed in the process, without
waking up.
Temporary sleep was handled (via checking for !mon->mcanmove) but
indefinite sleep wasn't. Make a monster hit by taming effect (either
magic or thrown food) wake up from indefinite sleep. For temporary
sleep, the remaining duration is cut in half. The timeout isn't
dropped all the way to 0 because a monster with mon->mfrozen set
isn't necessarily asleep. That timeout is shared by timed sleep,
timed paralysis, and busy time when donning armor.
If asked to create an Angel when MM_EMIN isn't specified, makemon()
will either create an ordinary monster of type Angel without any
emin extension or add emin and create a minion affiliated with the
god for randomly chosen alignment. Figurines didn't specify emin
so could result in either type, but wishing for them offered no
opportunity to specify alignment for the second type.
Change figurine activation to force the first type: an ordinary
monster of type Angel, not affiliated with any particular deity.
This is similar to the earlier potential fix that I didn't like,
but I think think one is better.
The analyzer claimed that 'fptr' might be Null inside the switch
case for
|struct permonst *fptr = NULL;
|if (obj->otyp == CORPSE || ...) fptr = &mons[obj->corpsenm];
|switch (obj->otyp) { case CORPSE: ... /* dereference 'fptr' */ }
even though it will always have a non-Null value for otyp==CORPSE.
Make the assignment of 'fptr' unconditional. mons[NUMMONS] is
valid and won't match any actual monster. In this case it will
only be used when initializing fptr, never when fptr gets used.
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Pull request #607 by Vivit-R proposed renaming "huge chunk of meat"
to "giant meatball" to better reflect the similarity to meatball.
But an object name that contains a monster name prefix requires extra
work in the wishing code. I considered "huge meatball" which retains
more of the original name but decided to go with "enormous meatball"
becaues it seems more evocative.
Supersedes #607Closes#607
The special handling of polymorphing corpses included an "is acceptable
food if starving" rule which ignored the pet's other food preferences,
so a starving herbivorous pet would become willing to eat a
non-vegetarian corpse iff the corpse would polymorph it when eaten.
Along the same lines but latent: if there were a vegan polymorphing
corpse, a carnivorous pet would eat it not only if starving, but also if
maltreated and on the verge of becoming feral.
Instead of trying to fix this by reimplementing all the herbi vs carni
rules specifically for polymorphing corpses, just have a "don't eat
polymorphing corpses if neither starving nor almost untame" rule, and
fall back to the normal palatable corpses tests once it's been
determined that the pet is willing to eat even a polymorphing corpse.
I rephrased the comment just to make it negative (about avoiding
polymorph, rather than polymorph being OK under certain circumstances)
to match the new form of the rule.
Avoid potential impossible "obfree: deleting worn object" warnings
when entering the endgame.
The code to get rid of items migrating to non-endgame levels passes
those items to obfree(). It needs to clear obj->owornmask first
because that's used for migration flags (undelivered orctown loot
has a non-zero value).
The earlier commit just removed monsters from migrating_mons and left
them orphaned. Also it ignored migrating objects.
Actually release the monsters that can no longer arrive at their
migration destinations. Release their inventories too.
Release objects that can no longer arrive at migration destinations.
When the hero enters the planes branch, all the rest of the dungeon
gets discarded since it can no longer be reached. At the time that
that takes place, throw away any migrating monsters waiting to arrive
on any of those levels.
When entering the Plane of Earth (or level teleporting directly to
another endgame level in wizard mode), if the Wizard came off the
migrating_mons list instead being re-created from scratch, he would
be placed randomly on the level instead of next to the arrival point.
If his mstrategy field still had the STRAT_WAITFORU bit set and you
didn't move to where he could see you, he might never come after you,
at least until some future harassment event chose 'resurrect'.
If the first monster on the migrating_mons list couldn't arrive and
was put back on the list to try again later, 'later' would happen
immediately and the program looped forever trying and failing to
bring that monster to the level.
Defer repeat attempts at migration until losedogs() has been through
the whole migrating_mons list. mon_arrive() now populates a new
list called failed_arrivals and losedog() moves its contents, if any,
to migrating_mons prior to returning.
Extend findgd() to bring a migrating guard back 'early' if there is
one and an active guard is wanted but none is present on the level.
It the level is full then the found guard is likely to be sent into
limbo (scheduled to migrate back), so one can end up moving back and
forth. Unlikely to occur during normal play.
Also, when a guard is needed and there's a dead one parked at <0,0>,
revive it. The dead guard has temporary corridor info in its
mon->mextra->egd that a new one won't have. (This might introduce
unexpected changes in vault behavior but if so, the old behavior was
probably buggy.)
When the hero is in a vault, don't find a guard unless u.uinvault is
ready to bring it into play. It was finding one every turn and then
ignoring the result for 29 turns out of 30.
Change guard appearance timing: the first appearance is still after
30 turns, but if it goes away, bring it back after 15 more turns
rather than another 30 and repeat as needed.
Issue reported by youkan700: for shopkeepers, taming via magic harp
behaved differently than taming via scroll or spell.
Make magic harp's taming be the same as [non-cursed] scroll of taming
and spell of charm monster: angry shopkeepers will be pacified (even
though they can't be tamed).
Also, add something I've been sitting on for ages: when taming magic
hits an already tame monster, give that monster a chance to become
tamer. Not significant for monsters that eat (unless being starved
for some reason) but matters for ones who don't eat. For tameness N
(which has a maximum of 20), if N is less than 10, have any taming
yield a 10-N out of 10 chance to increase the tameness by 1. So the
closer a pet is to becoming feral, the more likely for it to improve
tameness a little.
Closes#819
back into play with bad data
I don't have a test case to verify the fix, and I'm not absolutely
certain that the cause has been correctly diagnosed, but I think the
problem was caused by a guard being sent into limbo because the map
was too full to place it, then while it was on the migrating monsters
list waiting for a chance to come back the fuzzer executed #wizmakemap.
If the hero left the level and subsequently returned, the guard would
arrive back but monst->mextra->egd contained data for the previous
incarnation of the level that's invalid for wizmakemap's replacement.
Treat any shopkeeper, temple priest, or vault guard who is not on his
'home' level like the Wizard has been treated since 3.6.0. When
leaving the level they're on, put them on the migrating monsters list
scheduled to return to present position instead of stashing them in
the level's data file. That way they can be accessed from any dungeon
level, so wizmakemap can pull ones for the level it's replacing off
the migrating monsters list when removing the old level's monsters,
handling both migration-pending and already-arrived-on-another-level.
Bonus fix: put monsters who are on the migrating_mons list solely in
order to be accessible from other levels back first when returning to
the level they're on so that pets and the hero can't hijack their spot
when those arrive. The Wizard has been vulnerable to that.
Not fixed: #wizfliplevel command needs to flip parts of shk->mextra->
eshk and priest->mextra->epri for shk or priest on migrating_mons.
Vault guards don't contain anything flippable when migrating, but do
have coordinates that need fixing up while they're maintaining a
temporary corridor to/from the vault.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
When migrating, a long worm is removed from the map to take off the
tail, then its head is put back to be treated like other monsters.
If that occurred when being forced to re-migrate during failure to
arrive from a prior migration, it wouldn't have valid coordinates
and the place_monster attempt produced an impossible warning.
(Other types of monsters don't get removed and put back so didn't
trigger the problem.)
The routine to format a monster when the data is suspect mistakenly
thought it was dealing with a long worm tail because the monster
didn't match level.monsters[0][0], so the warning inaccurately
reported the problem as "placing long worm tail".
Reported by jeremyhetzler and confirmed by k2: dead monsters weren't
leaving corpses at the spot they died.
Don't set a monster's mx,my coordinates to 0,0 when taking it off the
map (unless it is migrating to another level; mx==0 is the bit of data
used to indicate that). Corpse drop happens after that and expects
the dead monster's former map coordinates to be intact.
Fixes#764
When wormgone() takes a long worm off the map, clear its stale mx,my
coordinates. None of its callers need those anymore.
Also a bit of potential long worm clean up that occurred to me when
I looked at object bypass handling. Expected to be a no-op here.
The change to zero out a monster's map coordinates when it is taken
off the map yesterday messed up migration between levels inside the
Wizard's tower. (Didn't apply when accompanying the hero between
levels, so probably unlikely to be noticed.)
Noticed while moving some replicated code into its own routine.
Reported directly to devteam by a hardfought player and also by
entrez. The recent mon_leaving_level() change resulted in objects
dropped by a dying monster not being displayed immediately.
It justed needed the relobj(mon, 0, FALSE) to relobj(mon, 1, FALSE)
change in m_detach() but this does some related cleanup in
mon_leaving_level()'s callers. wormgone() takes a long worm off the
map but leaves its stale coordinates set because some code relied on
that. This takes away the need for that but still doesn't actually
clear them.
This adds redundant 'return' statements at the end of a few void
functions that are longer than fits within a typical screen display.
They make searching for the end of the current routine in an editor
or pager easier without resorting to regular expressions and can
also be used to search for the beginning if/when preceding routine
ends in 'return' too.
From 6 year old email: m_detach (monster death or removal from play)
and relmon (monster migrating to another level) both take a monster
off the map but they weren't consistent with each other. Change them
to use a common routine for that.
I'm not sure whether the inconsistencies resulted in any bugs. The
email was concerned about handling for monsters that emit light, but
those aren't actually common to the two removal methods and turned
out to be ok.
Always give a message when creating a detected monster
during gameplay (as opposed to during level creation).
To prevent the message, use the MM_NOMSG flag for makemon.
Most places already handled their own messaging, but there
were some, such as bag of tricks, create monster magic
and random monsters created during gameplay that didn't.
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.
It's redundant with g.moves, so there is no more need for it.
Way, way back, it looks like g.moves and g.monstermoves can and did
desync, where g.moves would track the amount of moves the player had
gotten (and would therefore increase faster if the player were hasted)
and g.monstermoves would track the amount of monster move cycles, aka
turns. But this has not been the case for a long time, and they both
increment together in the same location in allmain.c. There are no
longer any cases where they will not be the same value.
This is a save-breaking change because it changes struct
instance_globals, but I have not updated the editlevel in this commit.
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.
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.
Use a linked list to store stair and ladder information, instead
of having fixed up/down stairs/ladders and a single "special" (branch)
stair.
Breaks saves and bones.
Adds information to migrating objects and monsters for the dungeon
and level where they are migrating from.
