Messaging for vampires changing into fog clouds was inconsistent
in 3.6.x but already fixed in to-be-3.7.
However, maintaining an extra set of shape change messages (one
in newcham(), the other in vamp_shift() which turns out to only be
used when a vampshifter turns into a fog cloud in order to pass
under a closed door) was a nuisance. Redo vamp_shift() to use
newcham() feedback. Update that feedback to be accessibility-aware
and also to use "Your <mon>" instead of "The <mon>" when appropriate.
While in there, remove a couple of trailing spaces and eliminate
use of one dynamically constructed format string that necessitated
warning manipulation.
Fix misleading indentation that the polyfood() macro inherited from
the misformated polyfodder() macro.
Fix a case where a non-pet monster would avoid eating a cockatrice
corpse but would eat Medusa's corpse.
'Polyfodder' is already a term frequently used by players to describe
items which are useful to hang on to specifically to zap polymorph at
(for example, extra unicorn horns, which can be turned into magic
markers). Using it as the name of a macro which tests whether a food
item will polymorph the creature consuming it is somewhat confusing, and
I think 'polyfood' is a lot clearer.
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
If the quest leader observes the hero attacking a peaceful monster,
only become angry if that peaceful monster is a quest guardian. And
when becoming angry, stop waiting for the hero to approach.
If a quest guardian observes the hero attacking any peaceful monster,
don't run away.
if Wizard escapes the dungeon
Reported by vultur-cadens: a fix to prevent quest feedback when quest
nemesis is removed from the game during bones creation introduced a
regression for an earlier fix that kept context.no_of_wizards up to
date if the Wizard of Yendor escapes the dungeon without dying.
Change 'wizdead()' to 'wizdeadorgone()' and call it from m_detach()
for mongone() as well as for mondead().
Fixes#1256
Issue reported by chadministratorwastaken: were-creature that was
ignoring Elbereth while in human form would make one more attack
after changing into creature form.
Have new_were() make an onscary() check when changing to beast form
while next to the hero. Do likewise for polymorphing creature.
Fixes#1253
Another tweak to PR #1240. Vampires start out vampshifted to
bat/fog/wolf form. Marking them as 'waiting' forces them back to
vampire form. Testing that revealed one of the brides as a vampire
lord rather than a vampire lady. That could probably be construed
as being politically correct but doesn't match the source material.
The reversion from vampshifted to vampire entailed a 10% chance of
toggling gender, comparable to hero self-polymorph. Don't do that
for vampires. From the player's perspective they change randomly but
from their own perspective, the change is controlled.
This makes it easier to understand what is happening in each of those
places, and also much easier to find the places that conversion between
hero and monster resistances happens (since you can now just grep for
"res_to_mr"). I think I got all the instances where the macro should be
used but I'm not 100% sure since there wasn't a single unique term to
search for to find them all.
I replaced the modifications to give_u_to_m_resistances made in the
previous commit, so that it now uses the same macro as other
conversions, since otherwise it would be much harder to find the
complete list of places where conversions between hero and monster
properties happen.
When mnearto() places a monster, it might remove another one to make
room, then try to put that second one back. If it can't do that, it
puts that other monster onto the migrating monsters list. But having
it already be off the map interferred with regular take-mon-off-map
handling that happens when setting up a migration.
If the other monster was a hider or concealed mimic, it wouldn't be
brought out of hiding. With 'sanity_check' enabled, that triggers
a warning when the occupants of migrating_mons get checked.
Testing this requires more effort than I'm willing to expend so there
might be unexpected consequences.
I still haven't found any explanation for the report by a hardfought
player recently that going down some stairs with a pair of leashed
pets got one into a confused state where it was flagged as leashed
but the corresponding leash was no longer in use.
This adds some new object and monster sanity checks regarding leashes,
and it changes o_unleash(obj) to clear obj->leashmon even if/when the
monster can't be found.
It also changes behavior for dipping an attached leash into a potion
of polymorph when that happens to yield another leash--now the new
one will end up being pre-attached.
Take advantage of the ability of some compilers to warn if
not all values are covered in a switch statement, to draw
attention to the need to update make_corpse() when new
monsters are added to NetHack.
This adds explicit entries for the current "default" handling
in make_corpse().
It might be a good idea to review the explicit entries to see
if any of them represent others that are not being handled,
but should be.
To test this, I temporarily reverted 85c86444, and I did receive the
following warning:
mon.c:545:13: warning: enumeration value 'PM_GOLD_DRAGON' not handled in switch [-Wswitch]
545 | switch (mndx) {
| ^~~~
1 warning generated.
In 3.6.2 parts of the wakeup code were merged together, and this
caused pets consider any noise made by the hero - such as hitting
iron bars or digging - as whistling for them to come to the hero.
Change it to only consider actual whistling and ringing a bell.
From a reddit thread: a 'mausoleum' theme room picked a vampire for
its occupant and applied the wait-for-you strategy to it. Hero's ESP
or monster detection showed a meditating vampire bat. Change monster
creation by the special level loader (which also handles theme rooms)
to force such a creature into its normal vampire form.
That revealed an older bug which wouldn't have been exercized prior
to theme rooms: a meditating vampire could and would shape change
without ceasing meditation. Make it not shape change rather come out
of its trance.
Re-use the array allocated for iterating over all monsters during
monster movement much of the time. It was being allocated from
scratch for each round of monster movement, then freed after they
moved, then repeated the next round.
While hunting for a memory leak in object allocation--which I haven't
found yet--I discovered one in monster movement. iter_mons_safe()
allocates an array of (monst *) pointers for the monsters on the
current level, loops over that array to call a function for each
one, then frees the array. But if the game ends while that called
function is running, execution never returns to iter_mons_safe() so
it wasn't able to free the memory.
Since that can happen at most once per game, it wasn't a signifcant
leak. This fixes it anyway.
There was a second issue: make sure that iter_mons_safe() doesn't
call alloc(0) to make the temporary array for zero monsters when
there aren't any on the level. That might not be able to happen for
monster movement but the routine is written to be more general than
just movement. alloc(0) could confuse the MONITOR_HEAP code. In
C89/C90 I think malloc(0) is allowed to return NULL (don't recall
for sure; maybe that was just known pre-standard behavior for some
implementations). Null return would trigger a panic even without
MONITOR_HEAP. Don't know about C99 and later.
Consistent with their mythological role of punishing those who had
violated societal taboos -- oathbreakers, hosts who attacked their
guests, etc -- erinyes scale with the cumulative amount of alignment
abuse the hero has committed over the course of the game. This is
tracked separately from the alignment record, and cannot be cleared by
the hero improving her favor with her god via "good deeds" as the normal
alignment record can. Erinyes will gain abilities, levels, and attacks
as the hero's alignment abuse worsens. They will also aggravate
monsters when near the hero.
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
corpsenm can be -1 (for EGGs and TINs) so touch_petrifies
using this as index would point to bad entry.
Fix this by making mstoning as helper function and bailing
out early if corpsenm <= LOW_PM (while keeping MEDUSA as is)
Issue reported by Umbire: an engulfing monster capable of passing
through iron bars (vortices and air elemental) could do so while
carrying the hero.
Prevent an engulfer from doing that unless the hero happens to be
polymorphed into a subset of the types of monsters that can move to
iron bar locations.
Fixes#1192
Adds a new boolean option, accessiblemsg. If on, some game messages
are prefixed with direction or location information, for example:
(west): The newt bites!
(northwest): You find a hidden door.
I added the info to the most common messages, but several are
still missing it.
Issue reported by Umbire: reviving a human corpse into a human
monster and then killing it entails murder penalty even when it is
hostile.
This is probably a non-issue. Human monsters tend to not leave
human corpses, they leave shopkeeper corpses or sergeant corpses
and so forth. Most human corpses created in normal play have
montraits attached and revive as a zombie, mummy, or vampire rather
than as a human.
This doesn't attempt to be clever, it just treats PM_HUMAN like
role monsters, not subject to 'murder'.
Closes#1180
