This tries to fix the problem of the extra message when a tame
golem is completely destroyed (paper or straw golem burned, iron
golem rusted, wood or leather golem rotted) being issued at odd
times. I basically punted on the visibility aspect since the
original logic was strange: you had to be able to see both the
attacker's and defender's spots and at least one of those two
monsters. Now mon-attacks-mon visibility requires that you be
able to see one of the two and if you don't see both, the unseen
one will be referred to as "it". The "may the iron golem rust
in peace" message is independent of that and may be displayed
after "you have a sad feeling", but now that's intentional and
will refer to an unseen pet by name or monster type, not "it".
This needs a lot of testing and hasn't attempted to address
issue #402: only some attacks that should compeletely destroy
a golem actually do so. (So a hit by fire elemental against a
paper golem does, but passive fire counterattack when a paper
golem hits a fire elemental doesn't, nor does a wand of fire
or being hit by Firebrand.)
Fixes#401
Monsters with rust attacks (rust monster) and corrosion attacks
(black pudding, gray ooze) can eat or otherwise destroy iron bars
but xorns could only move through the iron bars spot without being
able to eat the metal there. Change xorn to eat bars instead of
phazing through them. Lets rock moles eat bars too.
Hero polymorphed into a rust monster would eat bars if trying to
move to their location but couldn't do so if already there (maybe
was in xorn form and now in rust monster form). Xorns could pass
through them but not eat them. Allow hero metallivores to eat
bars at the current location via 'e', similar to eating food off
the floor. Hero as rock mole behaves like rust monster.
After 05403182eb (I think, possibly the
change to objnam.c which followed that one) from a couple of days ago,
wishing for a monster name dereferenced a Null pointer and crashed.
"were{rat,jackal,wolf}" each occur twice in mons[], once for the
beast form and second time among '@' for the human form. Wishing
for werecreature corpse or tin always matches the first entry so
yields the beast form, but all their beast forms are flagged as
no-corpse so the wish would fallback to a corpse with random monster
type. Wishing for werecreature figurine worked but always produced
one that created its beast form if/when activated.
This fix allows specifying "human werecreature" to match the second
entry. It's optional for corpse and tin; the wish code will now
switch to that implicitly if it gets a no-corpse were-form for
those. It has to be specified explicitly to get a figurine that
will activate as the human form. It works for ^G too.
Fixes#326
name_to_mon() has a bunch of alternate monster names, such as
"gray-elf" to match "grey-elf" and "ki rin" to match "ki-rin". Those
worked as intended when they occurred at the end of a wish, but only
worked in the middle if their length was the same or one character
less than the canonical name in mons[].mname.
djinni figurine -> h - a figurine of a djinni
genie figurine -> i - a figurine of a djinni
figurine of mumak -> j - a figurine of a mumak
mumak figurine -> k - a figurine of a mumak
figurine of mumakil -> l - a figurine of a mumak
mumakil figurine -> nothing fitting that description exists
(The one-less case worked because its following space ended up being
implicitly removed when skipping ahead by the length of mons[].mname;
subsequent explicit removal didn't find a space so was a no-op.)
The saying /corvus oculum corvi non eruit/ (Latin) means "a crow
doesn't pluck out the eye of another crow" (roughly). Something
along the lines of "like-minded people stick together". Honor the
literal meaning by preventing a raven's blinding attack that gets
directed at another raven from being able to cause blindness.
Fixes#293
Developed for 3.6 but deferred to 3.7. Most of the testing was with
the earlier incarnation.
Report was that pronouns were accurate for the underlying monsters
when hallucination was describing something random, and also that the
gender prefix flag from bogusmon.txt wasn't being used. The latter
is still the case, but pronouns are now chosen at random while under
the influence of hallucination. One of the choices is plural and an
attempt is made to make the monster name and verb fit that usage.
|The homunculus picks up a wand of speed monster.
|The large cats zap themselves with a wand of speed monster!
|The blue dragon is suddenly moving faster.
There is no attempt to match gender for the singular cases; you might
get
|The succubus zaps himself [...]
or
|The incubus zaps herself [...]
Noticed while fixing the 'monster intrinsics from worn gear' bug(s):
set_uasmon() calls set_mon_data(&youmonst,...) which updates movement
when the monster polymorphs into something slower, then it did the
same thing to youmonst.movement itself, hitting the hero with a double
dose of reduction for any movement points not yet spent on current
turn. Remove the set_uasmon() side of that, and change set_mon_data()
side to add a redundant non-zero test to prevent static analysis from
warning that it might be dividing by 0.
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.)
Similar to ^G of 'I' triggering impossible "mkclass found no class 35
monsters", using a leading substring of "long worm tail" (other than
"l" and "long worm") would trigger impossible "mkclass found no class
59 monsters and kill the fuzzer when it escalates impossible to panic.
Tighten up the substring matching.
^G of '~' wasn't affected; it deliberately creates a long worm rather
than the tail of one. But it was possible to ask for "long worm tail"
as a specific monster type and then override the switch to long worm
when prompted about whether to force the originally specified critter.
I've added a check to prevent that opportunity to override even though
a tail without a head seemed to be harmless.
Report stated:
type "watchmen" into a genocide prompt, it says no such creatures exist in the world
type "watchman" and it says "wiped out all watchmen"
fixes#151
Most shop messages accurately identify the shopkeeper even when he
or she can't be seen, but some also include a pronoun reference that
ended up as "it" or "its" when not seen. Extend pronoun selection
so that visibility can be ignored: noit_mhe(mon), noit_mhim(mon),
and noit_mhis(mon). Note that despite being called noit_foo(),
those will still return "it" if mon is neuter.
"Accurately identify shopkeeper" is misleading if the hero is
hallucinating; a random shopkeeper name is used then. noit_foo()
yields the pronoun applicable to the actual shopkeeper and might
not match the gender of a hallucinatory name. That could be fixed
in a couple of ways (add shk_mhe()/shk_mhim()/shk_mhis() and either
pass them the randomly chosen name so that they can figure out the
appropriate gender, or just have them use a random gender whenever
hallucinating) but I don't think that's worth bothering with.
A bunch of shop messages needed noit_foo(); only a couple of those
have actually been tested. A bunch more were using shkname() at
the beginning of a sentence where Shknam() should be used instead.
(All the existing shk names are already capitalized so there's no
noticeable difference.)
The three places outside shk.c and vault.c which directly use
pronoun_gender() have been successfully tested.
The original report complained that gremlins seemed impervious to
Sunsword's light yet a flash from a camera caused them to cry out in pain
despite "The long sword named Sunsword begins to shine brilliantly!"
This commit does two things:
1. A dmg bonus is applied against gremlins using a lit Sunsword.
2. Gremlins will generally avoid the light emitted by Sunsword.
There's a few minor flavor bits thrown in also.
It is understood that this effectively makes Sunsword provide
"gremlin-proofing", but the gremlin myth and Sunsword's characteristic
feature pretty much demand it.
bug 42
Reading a scroll while blind is permitted if you know its label, but
message is "as you pronounce the words, the scroll vanishes" unless
you are poly'd into a form which can't make sounds, in which case you
"cogitate" rather than "pronouce". Switch to the cogitate variant if
you are suffering from strangulation.
Casting spells didn't even have the distinction; you could cast them
without regard to speech capability. Check for that. Unlike with
scrolls, now you can't cast if you can't speak (or grunt or bark or
whatever) instead of having a variant description of the action, so
this is a bigger change.
Some discussion in the newsgroup about nearby peaceful monsters becoming
hostile if they observed the hero attacking a peaceful monster made me
look at the code and I spotted a couple of problems. An auto array was
being initialized in an inner block--some pre-ANSI compilers couldn't
handle that. Worse, it was inside a loop and may or may not have
resulted in unnecessary setup each iteration. Make it static. Oddly,
the array had the same name as a function but `gcc -Wshadow' either
didn't notice or didn't care.
A more significant problem was that mon->mpeaceful was being set to 0
without checking whether mon->mtame was set, potentially resulting in
humanoid pets being both tame and hostile at the same time. This change
prevents that but doesn't do anything interesting about pets who observe
attacks against peacefuls. (I also wonder why chaotic peacefuls now get
upset by seeing other peacefuls be attacked; it seems out of character.)
There was also a check for non-humanoid peacefuls seeing another of the
same species be attacked, but it was checking for an exact match without
regard for littler or bigger incarnations of the same species. I've
added the latter.
This also reformats a couple of block comments.
Blessed genocide of "titans" wiped out all quadrupeds because
"titan" is a prefix of "titanothere". After class letters and
class descriptions have been rejected, Have name_to_monclass()
resort to name_to_mon() instead of doing its own less detailed
name matching.
From a July 2011 report listing multiple movement anomalies, fix one
of the easier ones. If you polymorph from a fast from into a slow
one, pending movement points can let the slow form get in some moves
it shouldn't.
I've deliberately avoided adjusting pending movement when you change
into a faster form, which will get it's own movement boost on the
next turn.
Same sort of stuff as before: some continuation lines with operator
followed by end of line comment (only a few files with those still to
go...), plus tab replaced by spaces in comments, excess parenthesis
removal for return statements, and force function name to be in column
one in function definitions:
type name(args) /* comment */
argtype args;
{
to
/* comment */
type
name(args)
argtype args;
{
I've been spotting those by eye rather than rexexp, so probably missed
some.
Somewhere along the line I started removing redundant parentheses from
return statements, but only in files that needed continuation fixups
so it's not comprehensive.
Add macros W_WEAPON and W_ACCESSORY, similar to existing W_ARMOR, bitmask
of all the relevant worn bits. Just for code readability; there should
be no change in behavior.
Also, reformat the "ugly checks" portion of getobj(). Slightly better
readability and fewer continuation lines, but only a modest improvement.
When looking to see whether the monsndx() panic could provide any more
useful information [if a pointer that's supposed to point into the
mons[] array doesn't, I don't think that there's a whole lot of other
information available aside from whether it is null or not, and that's
implicitly provided already], I went through the whole file cleaning up
the formatting and making sure every routine was preceded by a short
(usually one line) comment.
There were a few bits of code reorganization. I changed little_to_big
to have a single point of return. The 25 year old workaround for a
compiler bug on a defunct platform may or may not still be applicable;
I took that out. If we get segfault reports for AIX on PS/2, this is
the first place to look. (big_to_little is nearly identical and didn't
have the same workaround. Not needed, or not called often enough for
any AIX PS/2 user to be affected?)
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Any monster with rusting or corrosion attack can eat through
the bars. This includes rust monsters, grey oozes, and black puddings.
Original patch by Malcolm Ryan
While testing the need-hands-to-open-tins patch, I tried to polyself
into a halfling and failed. Add it to the monster name lookup routine as
a variant spelling for hobbit.
This is mostly groundwork prior to making the Protection intrinsic
become more meaningful. The Mitre of Holiness (priest quest artifact)
and the Tsurugi of Muramasa (samurai quest artifact) will now confer
Protection when worn/wielded (though at present that effectively does
nothing). While in there, this also changes the Eye of the Aethiopica
(wizard quest artifact), the Eyes of the Overworld (monk quest artifact),
and the Sceptre of Might (caveman quest artifact) so that they need to
be worn/wielded rather than just carried in order for them to confer
magic resistance. That way they're a little less attractive for wishing
by other roles and a little more likely to be actively used by their own
roles (not an issues for the Eyes, I'm sure). This change actually works
to the player's advantage, since it means that monsters who successfully
steal those items won't instantly obtain magic resistance in the process.
This adds protects() as a predicate routine to check an item for
conferring Protection. In order to do that, it renames the existing
protects() routine to defends_when_carried(), because that predicate is
actually a variant of defends() for items which aren't worn or wielded.
When testing the change of "you can't polymorph into that" to
"you can't polymorph into <a monster type>" I noticed that specifying
high priestess told me that I couldn't become a priest (role monster),
but specifying high priest told me that I couldn't become a high priest
(monster as-is). Aligned priestess and high priestess aren't separate
monsters; the user-specific string to monster name code found the latter
as a rank title rather than as a monster and couldn't find the former
at all. This adds those two special monst types to the list of variant
spellings and whatnot that are used to augment name to type lookup.
Since they aren't viable candidates for polyself or for genocide I doubt
that any players ever noticed, so I haven't added a fixes entry for this.
From a bug report: amulet of strangulation
continues to kill hero if he polymorphs into a creature which doesn't
need to breathe or doesn't have a head or even a circulatory system.
Currently, the messages are different when the hero doesn't need to
breathe, but that doesn't seem good enough. This makes strangulation
stop when you polymorph into something which shouldn't be vulnerable and
restart if you poly into something vulnerable while still wearing the
bad amulet.
can_be_strangled() is doing more checks that necessary, in case the
strangulation property ever gets conferred by something other than an
amulet. Its criteria for protection from strangling might need tweaking.
Another item from the Dec'04 report sent in by <email deleted>. When prompted for a type of monster to polymorph
into, giving a monster class description like "dog or other canine" (or
single letter like 'd'), triggered "I've never heard of such monsters".
Instead of adjusting the message, this chooses a member from the class.
I put this into the fixes file as a new feature.
