The recently added sanity check for monster maximum HP was giving
false complaints when Nd8 monster had N mhpmax. Most noticeable
for level 1 monsters (level 0 monsters use 1d4 instead of 0d8 and
weren't affected) but possible for higher level ones if they were
unlucky--from their own perspective--with all their d8 rolls.
Give level N monsters a minimum of N+1 HP, so minimum of 2 for
level 1 monsters, making 1/8 of those stronger. Same minimum for
level 0 monsters, 25% of which will become stronger now. (The pull
request's patch gave every Nd8 monster 1 extra HP; this only does
so for Nd8 and 1d4 ones which have rolled lowest possible amount.)
Also relax the sanity check so that existing to-be-3.7 save files
don't continue to trigger sanity complaints for existing monsters
that have the old minimum.
Fixes 365
montraits() didn't have any handling for long worm tails, makemon()
didn't have any provision for creating a long worm without a tail,
replmon() uses place_wegs() to put tail segments on the map when
replacing a dummy new monster with the mtraits one but place_wsegs()
wasn't updating the head segment since it isn't put on the map.
That turned out to be key because there is always an extra segment
co-located with the monster and when its coordinates were wrong,
worm_known() gave bad results for visibility checking. The
statue-goes-away message was the one for not being able to see the
monster that it just animated into, even though 'w' appeared at the
spot. It took quite a while to track down what was going on there.
Sanity checking for worms has been updated and could conceivably
start triggering complaints about things that it used ignore.
The recent change to mkclass() was letting genocided monsters be
created when role-specific monsters were chosen for quest levels.
makemon(Null) -> rndmonst() -> qt_montype() -> mkclass() -> mk_gen_ok()
was accepting members of the quest-specified class even when they
should have been rejected. I'm still not sure why the revised bit
manipulation didn't work as intended; the re-revised code does.
G_IGNORE was a bug waiting to happen since it gets passed to
mkclass() as a mons[].geno flag but is used to control the use of
mvitals[].mvflags values. It's still being misused but at least
it doesn't conflict with any of the other flags now.
Fixes#352
Accept or ignore the in-hell-only and non-in-hell-only flags on
a monster type by monster type basis instead of all or nothing
for a given mkclass() call. Prevents demon summoning outside of
Gehennom from bringing in only succubi and incubi 10 times out
of 11 and mixture of demons the other time.
Change mkclass() to always honor the hell-only monster generation
flag for L class, preventing master and arch-liches outside Gehennom.
For other classes, honor hell-only and outside-hell-only most (89%)
of the time. When not honored (11%), it allows demons and devils to
appear outside of Gehennom as they have in the past. [That part
might need to be re-done since it is done for all monsters in the
class on any mkclass() call instead of being done on a class-member
by class-member basis within each such call.]
This prevents out of depth liches in the Castle and ought to do same
for themed rooms of type 'Mausoleum' although I haven't figured out
how to test that.
Fixes#349
I added another goodpos flag to simplify handling displacer beast
and that pushed the total number of makemon and goodpos flags past
16. 'int' and 'unsigned' might be too small, so change the flags
and several function arguments to 'long'.
Make a mimic that picks special VEGETARIAN_CLASS look like food
instead of a random object. Also, at least a couple of Minetown
variants are classified as mazes so had a 50% chance of not even
making that choice and look like a statue instead. Override maze
when 'in_town()' yields True.
Health food stores use a special "vegetarian class" of items,
which mkobj doesn't understand. Just make the mimic use a random
item class in that case.
The impetus for this was to avoid ugly constructions such as the one
below (none of which currently appear in vanilla NetHack):
mongets(mtmp, LONG_SWORD);
struct obj* sword = m_carrying(mtmp, LONG_SWORD);
if (sword)
/* do thing to sword */
Most cases where mongets is used discard the returned value (which used
to be the created object's spe); the only places that do use it are the
series of statements that give various human monsters armor and prevent
them from getting too much armor. These statements included hardcoded
constants representing the base AC of the armor, which would have caused
discrepancies if armor's base AC were ever changed.
With mongets now returning a pointer to the created object, it can just
be passed into ARM_BONUS instead, which covers both the base AC and the
enchantment. (It will also cover erosion, if anyone ever decides that
armor should rarely generate as pre-eroded).
The overall algorithm is not changed by this; human monsters should
receive armor with the same probabilities as before.
This makes a lot of sense. Why would they hate one artifact sword so
much and not really care about the one that is especially designed to
kill their type personally?
Report complained about multiple Archons causing his character to
be swarmed by monsters on the Plane of Fire. I don't think that
the behavior has changed significantly from how it worked in 3.4.3.
Nobody can summon an Archon directly because they're excluded from
the nasties[] list. But whenever summoning picks a genocided
'nasty', the result gets replaced by random monster of appropriate
difficulty for the level (which could be an Archon for a high level
character in the endgame). [Note that that won't pick an Archon
in Gehennom or at arch-lich outside of there because the random
monster creation honors the only-in-hell and never-in-hell flags;
picking from the nasties[] list doesn't.]
This prevents that for any creature (except arch-lich or the Wizard)
casting the summon nasties spell. If a replacement creature is a
spellcaster it now has to have lower difficulty than the summoner.
If not, it will be discarded even though its difficulty is classified
as appropriate. So to summon an Archon, the summoner has to have
higher difficulty than an Archon; arch-lich and the Wizard are the
only ones meeting that criterium. When summoner is an arch-lich,
it can't summon another arch-lich (since that wouldn't have lower
difficulty than the summoner) and can summon (via replacement for
genocided type, and only if outside of Gehennom) at most one Archon.
When summoner is the Wizard, he could summon an arch-lich (when in
Gehennom; demoted to master lich elsewhere--see below) or an Archon
(outside Gehennom only), but at most one per summoning.
For post-Wizard harassment, which effectively has infinite
difficulty level, it could still happen. However, each instance of
harassment is only allowed to create at most one Archon or arch-lich
now, so chain summoning should be lessoned. Also if it tries to
pick an arch-lich when outside of Gehennom it will switch to master
lich instead (which won't be allowed to summon an Archon or an arch-
lich or even another master lich).
(The monmove.c bit is unrelated, just some comment formatting that
I had laying around that got mixed in.)
If a special level explicitly requests eg. a statue with a genocided
monster class, allow generating it.
Rationale is that those objects were generated before the monsters
became extinct. Also fixes a lua error.
Eliminate the cache that was supporting rndmonst() and pick a random
monster in a single pass through mons[] via "weighted reservoir
sampling", a term I'm not familiar with.
It had a couple of bugs: if the first monster examined happened to
be given a weighting of 0, rn2() would divide by 0. I didn't try
to figure out how to trigger that. But the second one was easy to
trigger: if all eligible monsters were extinct or genocided, it
would issue a warning even though the situation isn't impossible.
Aside from fixing those, the rest is mostly as-is. I included a bit
of formatting in decl.c, moved some declarations to not require C99,
and changed a couple of macros to not hide and duplicate a call to
level_difficulty().
Fixes#286
This feature is originally from SliceHack, but the original code
directly edited the monmove code, whereas I thought it was cleaner to
use the existing mtrapseen code. Thus, this commit just marks trapdoors
as "seen" for all non-mindless monsters generated in the Castle level
(the same way all monsters in Sokoban are marked aware of pits and
holes).
This change prevents these Castle monsters from moving onto trapdoors
97.5% of the time. (A determined player can still patiently sit and wait
for everyone in the castle to plunge like lemmings into the trapdoors,
but it will now take 40 times as long.) Also unlike SliceHack, this only
excludes mindless monsters - not all non-humanoids. There are plenty of
intelligent non-humanoid monsters generated right next to the trapdoors,
after all.
This is aimed at better flavor (the inhabitants of the castle should
know about the traps in their own area) and better scenery in the Valley
(doesn't seem as much of a valley of the dead if there are hordes of
soldiers milling around down there).
I considered sticking an in_mklev condition onto this if statement, so
that monsters spawned into the Castle after its creation will fall down
the trapdoors, but ultimately decided against it.
When GOLDOBJ was activated unconditionally, several texts started referencing
"money" instead of "gold".
As we don't have the intention to introduce a complex coin system with
different denominations, change it back and also some other places that
reference "money".
A reddit thread about an unaligned altar in an aligned temple was
a tipoff that mimics posing as altars didn't have any particular
alignment. The look-at code was misusing an operloaded field of the
underlying terrain. Pick an alignment at random when taking on the
appearance of an altar, store it in the mimic's mon->mextra->mcorpsenm
field, and have look-at use that.
Also, dropping a ring of polymorph into a sink can transform it, and
one possible outcome is an altar. In this case, the alignment is
part of the location's topology, but code setting that up was using
Align2amask(rn2(foo)). That's a macro which evaluates its argument
more than once. The first evaluation was effectively a no-op. If
the second evaluation picked lawful then the result was lawful as
intended. But if the second picked non-lawful and the third picked
lawful, the result would end up as none-of-the-above (a value of 3
when it needs to be a single-bit mask of 1, 2, or 4).
With 3.7+ aspirations of improving savefile interoperability between 32-bit
and 64-bit builds, as well as between platforms, it is better to not have
the underlying struct/array content be conditional.
This splits off some of the MAIL code into MAIL_STRUCTURES code. In theory,
since MAIL_STRUCTURES is unconditionally included, the macro could
just go away and leave that code unconditional, but this commit doesn't
go that far.
Mimic-as-slime_mold needs to keep track of the fruit index the same
way that mimic-as-corpse keeps track of corpse's monster type. The
mimic description was changing (for '/' and ';' feedback) whenever
the player assiged a new fruit name.
That wasn't noticeable when applying a stethoscope because
mimic-as-slime_mold always yielded "that fruit is really a mimic".
Change it to report the fruit's type instead of generic "fruit".
Sword given to angels used obj->spe = max(obj->spe, rn2(4)) [except
using a temporary to sanely work with max() macro]. But the obj was
explicitly created as no-init, so obj->spe was always 0 and the max()
was pointless. Shield given to angels was manipulating bless/curse
state directly instead of using the functions intended for that, a
no-no and also pointless to be clearing 'cursed' for a no-init item.
Mace for priests had useless handling for object creation failure.
Object creation failure could only happen if the mksobj() call had a
valid entry in objects[] (or out of bounds access that didn't crash)
for an object class that it doesn't know how to handle. That can't
happen unless somebody screws up big time. If it ever did happen,
it would have produced a memory leak.
Express the logic of various early returns more consistently.
clone_mon() wasn't handling mon->isminion correctly. I'm not sure
whether it is actually possible to clone a minion (maybe after
polymorphing it into a gremlin or blue jelly?). When it wasn't tame,
which is the case for every minion other than the guardian angel on
Astral, the emin structure wasn't being allocated for the clone but
its isminion flag was left set.
Also, clones inherited mon->mtrack[] so would unnecessarily avoid
moving onto spots the original had recently moved across.
Cloned pets are inheriting various pet-specific fields that they
probably should be starting with a clean slate on but I haven't made
any attempt to address that.
While testing, I noticed that I could completely fill the Water level
with air elementals.
Hero can't fly or levitate or water walk into/onto water locations
on Water level without drowning/crawling out the water, and monsters
shouldn't have been able to but could, then they were hit by drowning
since minliquid used different criteria than movement. But goodpos(),
used for teleport destination and new monster creation among other
things, consided water locations acceptable on that level for
non-aquadic creatures with Fly/Lev/Wwalk ability.
It explains why so many dragons and other 'nasty' monsters have been
ending up on the vanquished monsters list when hero uses level
teleport to go directly there from level 1. They've either been
getting created in water and then they drown when it's their turn to
move or moving into it to approach the hero and drowning (not sure
whether that case is immediate or on next move). There's no message
since hero doesn't see it, and air elementals didn't drown since thy
don't breathe.
When cloning a monster, clear the clone trapped and hiding states.
When splitting a monster (eg. a black pudding), the clone could
be placed on a trap, so do mintrap.
When removing a monster from the map, clear the trapped state.
Vlad keeps his own form when carrying the Candelabrum, but if you
manage to get that away from him he should behave like other vampires.
He wasn't though; a high level wizard casting polymorph on him would
change him into an arbitrary monster rather than into a wolf/bat/cloud
that revives as Vlad when killed.
Noticed while looking over mimic hiding. When on an object, a mimic
will hide as that type of object. But for a corpse, it picked a random
monster type and could choose one that doesn't leave a corpse. Also as
a tin it would always be an empty one, but there doesn't seem to be any
way for a player to learn that.
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.)
