<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.
