flooreffects() covers most dropped/thrown/etc. cases, and the hooks in
invent and mon handle "deathdrops" along with picking up items.
still need to check putting into/removing from containers
Revert a change from five weeks ago which added M1_NOHANDS to the
jabberwock definition. The jabberwock illustration from Lewis Carroll's
_Through_the_Looking_Glass_ depicts one with its forelegs held like arms
and the forefeet look like clutching hands. Enormous hands, but
nethack's one-size-fits-all object model means they can manipulate things
just like anybody else's hands.
Jabberwocks are flagged as animals hence won't use items, or else
this would have been obvious long ago. They weren't flagged as no-hands,
so a hero in their form could wear gloves and/or wield a weapon (or a
cockatrice corpse, whose ineffectiveness when used with a claw attack
which followed a bite attack led to the discovery of this oversight).
I'm not sure what a jabberwock ultimately looks like, but am pretty sure
that it shouldn't have usable hands, particularly ones which are only
usable by a poly'd hero and not by jabberwock monsters.
add SYSCF docs to the Guidebook because it's info needed in a binary distro
Guidebook.tex - also add some missing italics to some "NetHack" occurances
call nethack.org "official"
Guidebook.txt - didn't regenerate cleanly so no diff
add SEDUCE to SYSCF (only partly inspired by the recent email)
I did some research, and technically, a jellyfish does indeed have no head
(and, technically, no brain, just a "nerve net"). The part on top is a
"bell" used for buoyancy, not a head.
During some recent newsgroup discussion, <Someone> posted an entry from
his personal bug list: energy draining damage from ordinary attacks is
implemented even though there are no monsters with that capability and it
was not implemented for engulf attacks even though energy vortices have
the capability. This implements energy drain engulf attacks against the
hero and also both modes of energy drain attacks for monsters and poly'd
hero against spellcasting monsters. Since monsters don't have energy,
they lose access to their special abilities (their spells, that is) for a
few turns, same as a post-3.4.3 change done for anti-magic traps.
Reported two months ago by <email deleted>,
having a water elemental become trapped in a bear trap seems pretty
strange. Fixed by marking water elementals as M1_UNSOLID (like air and
fire elementals), which has a side-effect of making them immune to webs
as well. Tweaked some unused digging code which checks unsolid(), added
unsolid() to the types allowed to bar through iron bars, and brought the
check for whether a monster is willing to enter a bear trap location up
to date. That code also needed an update to reflect the change made to
anti-magic traps last year. Lastly, there was another report which
suggested that being hit by a bear trap should dish out some damage
(along with a suggestion that wand of opening should work to escape such
traps, which has already been done). This makes bear trap do 2d4 damage
(on entry, not when trying to pull out after becoming stuck).
From a bug report, the fallback selection criteria
(used when everything is extinct?) in rndmonnum() was excluding hell-only
monsters when outside of Gehennom, but failed to exclude never-in-hell ones
when inside. [Some of the never-in-hell monsters are Angels, but the rest
are all cold based creatures. That must date to when fire resistance was
required for the hero, which is no longer the case. Should those cold
monsters retain their never-in-hell setting?]
This also fixes a latent copy/paste bug in the unused mons[] definition
of Cerberus (it was the only unique monster which failed to specify G_NOGEN).
- restore intended behaviour of kill_genocided_monsters().
It has been incorrect since the chameleon overhaul in June 2004.
- eliminate CHAM_ORDINARY and use NON_PM instead.
Between the addition of worm body parts and the phrasing of engulfing/
digesting status, I remembered an oddity with the vanquished monster list:
it shows baby long worms right next to adult long worms; both were defined
as level 8 monsters. It also turns out that babies dealt more damage per
attack than adults; that was counterintuitive, to put it mildly. Boost
long worms from level 8 to 9; drop baby long worms from level 8 to 5, half
rounded up just like the relationship between baby and adult purple worms
(who are levels 8 and 15, respectively). And increase the damage for adult
long worm attack (was 1d4, now 2d4); drop it for baby (was 1d6, now 1d4).
I doubt if many players in nethack ever have pet ghouls (in slash'em
they're the necromancer's starting pet), but if so, provide them with a
portable food source by letting ghouls eat dead eggs in addition to tainted
corpses. Also, let them eat fresher varieties of either when they're about
to starve to death. Treat lizard & lichen corpses as always fresh since
they never become tainted (probably ruining slash'em necromancers' present
pet food of choice, though they'll still be able to eat lizard corspes if
starving).
I set the omnivore flag in their monster definition. Previously they
had been left as non-eaters despite the fact that they need to eat. When
the flag wasn't set, a hero who poly'd into one and then put on an amulet of
unchanging could go a very long time (thousands of turns) before the hunger
imposed by wearing an amulet finally made him/her become hungry. (Same as
with any other truely non-eating monster, so not really a big deal.)
Also, avoid the expression &mons[obj->corpsenm] for objects where the
corpsenm field isn't applicable, in case the default value ever changes from
0 (PM_GIANT_ANT) to NON_PM (-1).
Combo fix based on several reports and additional research.
In quest.txt and/or data.base, the Grand Master, Arch Priest, Ixoth, Master
Kaen, Nalzok, Scorpius, and the Master Assassin are all referred to as male
via reference: his or him. Ideally, there would be a way to parameterize
this in the quest.txt, but I don't see a clear way to do that at this time.
For the time being at least, set the M2_MALE flag for these monsters.
The Dark One was referred to via "his" once in the quest.txt. This case
I was able to modify the offending text rather than forcing a gender.
Orion and Norn are referred to as a giant in data.base but their size did
not correspond. I left the symbol as S_HUMAN although perhaps it should
be S_GIANT. Finally, Orion, the Norn, Cyclops and Lord Surtur, as
giant-types, should be able to tear webs.
Note: The CVS repository was tagged with NETHACK_PRE_MEXTRA
prior to application of this patch to allow easy withdrawal if necessary.
Adds a new mextra structure type that has a set
of pointers to various types of monster structures
including:
mname, egd, epri, eshk, emin, edog
Replaces the mextra bits in the monst structure
with a single pointer called mtmp->mextra of type
(struct mextra *).
The pointer can be null if there are no additional
structures attached. The mextra structure is not
adjacent to the monst structure.
Reduces the in-memory footprint of the monst that
has no other structures attached, at the cost
of adding 6 extra long ints per monster to
the save file
The new mextra structure has the mextra fields
independent of each other, not overlapping as was
the case with previous NetHack versions.
This patch doesn't do anything to capitalize on
that difference however.
Consolidates vault.h, epri.h, eshk.h, emin.h and edog.h
into mextra.h
Adds a macro for checking for whether a monster has
a name:
has_name(monst)
This fixes the magic trap panic
expels() -> spoteffects() -> dotrap() ->
domagictrap() -> tamedog()
because the monst no longer varies in size so no
replacement is required.
Another one from <email deleted>: freezing spheres have the NOTAKE
attribute but flaming and shocking spheres don't. That means that tame
critters of the latter two types will pick up and drop things. I only saw
it happen with single gold pieces in my limited testing; I guess they're
really weak.
This one sounds sort of familiar; I think it might have been reported
before. The fix is so trivial I don't know why it didn't happen.
Angels used the epri extension even though they're never priests,
presumeably because they're sometimes flagged as "renegade". Since the
only priests ever flagged as renegade are roaming minions rather than
temple priests, move the renegade flag to the emin extension and switch
Angels over to that. Summoned Angels will now always have the isminion
flag set.
Makefiles need updating: monst.{c,o} now depends upon emin.h.
<Someone> wrote:
> From the mkclass() comments:
>
> /* Assumption #2: monsters of a given class are presented in ascending
> * order of strength.
> */
>
> And monst.c:
>
> * Rule #2: monsters of a given class are presented in ascending
> * order of strength.
>
> * Rule #4: monster subclasses (e.g. giants) should be kept
> * together, unless it violates Rule 2. NOGEN monsters
> * won't violate Rule 2.
>
> Inspecting my monster-difficulty spoiler, I see the following places
> that these precepts are violated: do they cause potential problems?
> (Insofar as occasionally incorrectly miscalculating the probabilities
> for monster generation is a "problem", that is...)
>
> SPECIES DIF
> ~~~~~~~~~~~~~~~~~~~~~~ ~~~
> d dog 5
> d large dog 7
> d dingo 5
>
> d warg 8
> d winter wolf cub 7
> d winter wolf 9
>
> u white unicorn 6
> u gray unicorn 6
> u black unicorn 6
> u pony 4
>
> H frost giant 13
> H storm giant 19
> H ettin 13
>
> P black pudding 12
> P green slime 8
>
> S pit viper 9
> S python 8
> S cobra 10
>
> Z giant zombie 9
> Z ghoul 5
>
> @ nurse 13
> @ soldier 8
> @ sergeant 10
>
> & horned devil 9
> & succubus 8
>
> & balrog 20
> & sandestin 15
>
> (I've just realised that these may have already been fixed, and
> waiting on a file-compatibility-breaking release; if so, ignore me :-)
- can shift into fog clouds, vampire bats, and vampire lords into wolves
- after being "killed" in shifted form, they transform back rather than get
destroyed, and you must take them on in vampire form to defeat them
- can deliberately shift into fog clouds to pass under closed doors
This is a foundation patch for patches to follow.
- use a full short index for mon->cham field.
- The current system of providing CHAM_XXX values
was limited to the 3 bits allocated in the bitfield and invalidated
save/bones if the field was expanded.
- The current system didn't provide an easy backwards change
if multiple monster types wanted to use the bit, there was a one
to one mapping: For instance, if you wanted a CHAM_VAMPIRE,
and you wanted vampires, vampire lords, and Vlad to use it, you
would have to have CHAM_VAMPIRE, CHAM_VAMPIRE_LORD,
and CHAM_VLAD defined to achieve that with the one-to-one backward
mapping.
- This new way just uses the mon[] index in the mon->cham field and
eliminates the need for CHAM_XXX (CHAM_ORDINARY is still used).
- no longer requires the cham_to_pm mappings
For now, the code is conditional on BARGETHROUGH
being defined, while it gets tested further. While behavior is
different with and without BARGETHROUGH defined, savefiles
are the same either way.
After this patch is applied, only the riders have the M3_DISPLACES
bit set, but the Wizard and Vlad probably should too. Any others?
<Someone> suggested that nagas should eat. This seems reasonable.
I made all but the black omnivores. The black are similar to the AD&D
spirit naga, which are listed as carnivores, while AD&D's other nagas are
omnivores, so I took the same approach.
<Someone> wondered post-3.4.1 why paper golems are affected by cold.
Given what I know of paper, straw and wood, and fantasy golems of each
type, all three types of golem seem like they should resist cold. The
others were less clear to me, someone else can address them if necessary.
<Someone> reported that couatl and ki-rin could wear boots and gloves.
Two problems: 1. all minions were created with a sword and armor, even those
that couldn't use them. 2. couatl and ki-rin were missing some important
bits in their M1 flags.
Now neither couatl or ki-rin are created with armor, and they won't try
to wear any armor they cross in the dungeon.
<Someone>:
Baby shimmering dragons have been made DRAGON_SILVER. Adults are still
cyan, as are their scales. Not that it matters while they're still
commented out, but why the discrepancy?
Back in 2000 "Pat Rankin" wrote:
> From a user (in a message which had several unrelated things):
>
> > I think the colour of silver dragon scales / scale mail should not be
> > SILVER (which is not a colour), but HI_SILVER. Of course the colour of
> > silver dragons would have to be adjusted to match this.
>
> I don't normally have access to a color display, so I hadn't noticed
> that silver dragons are CLR_BRIGHT_CYAN. It is pure coincidence
> that material SILVER happens to have the same numeric value as that.
> Is bright cyan intentional, to make them distinguishable from gray
> dragons (since color HI_SILVER is defined to be the same as CLR_GRAY)?
> Or was it done for the monsters just because the corresponding objects
> accidentally had the wrong value? It seems to me that they ought to
> be the same shade of silver (ie, gray) as other silver things, even
> if that makes them look identical to gray dragons.
Using the material value SILVER in the "color"
field was wrong, no matter what the reason. I
suspect it was probably a mistake originally.
This patch does not alter the displayed colour for the
bug-fix release, but does correct the misuse of the
material.
Make all the quest nemesis monsters resist stoning so their death messages
make sense. Some already did resist. Stoning seems like such a trivial
way to overcome a quest nemesis anyway. If it were to be allowed, multiple
death messages would be needed in the quests.
