Enlightenment and end of game disclosure didn't report level-drain
resistance if that was obtained via wielding Excalibur (or Stormbringer
or Staff of Aesculapius). Drain_resistance wasn't one of the attributes
set for intrinsics/extrinsics when wielding or unwielding weapon or
wearing/unwearing other equipment. loseexp() checks resists_drli()
which does check for items in use, so level drain would be aborted,
possibly after messages claimed that it was taming place. I didn't try
to untangle any of that, just changed set_artifact_intrinsic to include
a test for DRAIN_RES.
Reformat some trailing &&, || operators followed by end-of-line comment,
missed by the earlier continuation formating.
An
#if 0
something {
#else
something_else {
#endif
construct in rhack(cmd.c) confused the automated reformatter, resulting
in some code from inside a function ending up in column 1.
Mostly && and || at end of the first half of a continued line rather
than at the start of the second half. The automated reformat got
confused by comments in the midst of such lines.
foo ||
bar
was converted to
foo
|| bar
but
foo ||
/* comment */
bar
stayed as is.
Some excluded code [#if 0] was also manually reformatted, but this is
mainly stuff that can be found via regexp '[&|?:][ \t]*$' (with a lot
of false hits for labels whose colon ends their line).
Require the hero to pass the next_to_u() check when using the Eye of the
Aethiopica to portal to another dungeon branch. Even though the reported
exploit of having a steed which is carrying the Amulet bring it along had
already been prevented, this changes the temporary portal behavior to be
like level teleport. A steed carrying the Amulet or a non-adjacent pet
on a cursed leash will inhibit the attempted change of location.
If Sting is glowing when blindness gets toggled, give a new "glowing"
message.
So instead of
Sting glows blue! [...] You can't see! [...] Sting stops quivering.
if you're still blind when the last orc goes away, or
Sting quivers slightly. [...] You can see again. [...] Sting stops
glowing.
if you were blind when the first orc arrived, now you'll get an
intermediate message between the second and third ones. 'Sting is
quivering' for the first case, 'Sting is glowing' for the second.
No matter how many times blindness toggles back and forth, the final
"stops glowing" or "stops quivering" will be consistent with the most
recent "is glowing" or "is quivering".
Add "(glowing light blue)" to the formatted object description when
Sting or Orcrist is glowing due to presence of orcs or "(glowing red)"
if Grimtooth is glowing due to elves. Use "(glowing)" if blind;
assumes that some aspect of the glow (perhaps warmth or vibration) can
be noticed via touch.
Make enlightenment's "you are warned about <monster class> because of
<artifact>" catch up with Orcrist and Grimtooth. It was attributing
Orcrist's warning against orcs to Sting, and Grimtooth's warning was
against "something" rather than elves.
The glow color is now a new field in artilist[], so the biggest part
of this patch is adding an extra value to each artifact's definition.
Make Orcrist glow light blue when orcs are present, just like Sting.
(Sting supposedly glowed because it was made by the elves of Gondolin
rather than any particular attribute built into it, and Orcrist was
made there too. I think it also glowed in the Hobbit; that was how
Bilbo recognized what the situation was when he first saw Sting glow.
Maybe it was the other sword rather than Orcrist, but they were treated
as being functionally equivalent.)
Also make Grimtooth glow red when elves are present. That's from thin
air, to give it some novelty. Unlike Sting, whose double-damage bonus
is restricted to orc targets, Grimtooth's weak 1d6 bonus still applies
to all targets.
Give an alternate message if Sting starts or stops glowing while the
hero can't see. It probably ought to give an immediate message when
blindness toggles but that looks like it could get messy.
Having an 'o' die or migrate off level should probably also redo the
Sting message immediately, otherwise we see things like:
The little dog kills the goblin.
The little dog eats a goblin corpse.
Sting stops glowing.
(There could be lots of additional intervening messages depending on
other monster activity at the time.) Calling see_monsters() in the
relevant places--probably m_detach() and migrate_to_level()--would
address this but won't do because that could result in hallucinating
monsters changing appearance mid-turn.
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!
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
Simplify retouch_equipment (post-3.4.3.code, called when hero
changes alignment or turns into a silver-hating critter; inventory
traversal must cope with the possibility of losing object->nobj when
processing object) by switching to recently added object->bypass code.
After newsgroup discussion of C343-162, I noticed that it had fixed
the verb usage in the message for confused and/or stunned, but not in the
one for resisting. (If a monster name ends in 's', or it has been named
"you", 3.4.3 used the wrong verb because vtense() was fooled about plural
or second person.) No new fixes entry needed....
Simplify many of the intrinsics macros from
#define xxx_resistance (Hxxx || Exxx || resists_xxx(&youmonst))
down to
#define xxx_resistance (Hxxx || Exxx)
by setting or clearing an extra bit in Hxxx during polymorph so that the
resists_xxx() check becomes implicit.
Unfornately there were lots of places in the code that treat Hxxx
as a timeout number--primarily for Stunned, Confused, and Hallucination;
Stunned happens to be one of the revised macros--rather than as a bit
mask, so this patch needed a lot more changes than originally antipated.
Use the grave accent (back tick) character as the keystroke for a
new command which prompts for an object class and then shows a subset of
the discovered objects list covering just the selected class. Similar
to the 'I' variant of 'i' for viewing inventory, and mainly useful once
the '\' discoveries list has grown long.
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.
From the newsgroup: if no co-aligned artifacts are available when
attempting to give the first divine gift for an offered corpse, nothing
would be given. Since the gift counter stayed at 0, subsequent attempts
to select one would still treat it as first gift and always fail again.
The first divine gift from offering corpses must match the hero's
alignment; after that, nonaligned artifacts (Frost Brand, Giant Slayer, &c)
are added to the pool of choices for further divine gifts. It's pretty
easy for a chaotic character to use up the co-aligned artifacts before
getting any divine gift. There aren't many chaotic ones and some are
inelgible due to being race-specific items. Wishing for Stormbringer--or
loading a bones file which contains it--and creating Sting and Orcrist
via naming will do the trick for an elven hero.
This patch expands the pool of candidates to include nonaligned
artifacts during first gift selection if no co-aligned ones are available.
The one `anything any' that was triggering a warning was shadowing
another `anything any' in the same function; no need to rename it, just
remove the unnecessary declaration. Also, mark the couple of arrays with
initializers that I'd noticed as static instead of letting them default
to auto. The abil_to_spfx()::abil2spfx[] one might need to be redone in
code as a switch if some compilers/linkers have trouble initializing it.
Groundwork for re-doing ^X so that it'll be more integrated with
enlightenment and display bottom line information without abbreviations
or long-line truncation. `mode' doesn't do anything yet so may provoke
lint complaints.
From a four year old news posting: hero was levitating via #invoke
on the Heart of Ahriman, then dropping that artifact yielded:
You drop a gray stone named The Heart of Ahriman.
You float gently to the floor.
A gray stone named The Heart of Ahriman hits the floor.
That might be strictly correct, assuming that both hero and stone fall at
the same speed; if the stone was dropped from perhaps waist height then
the hero's feet would touch first. But it looks strange, like a cartoon
where something hangs in midair until someone notices that it should fall.
Removing the artifact from inventory causes the #invoke property to
toggle off. Unfortunately it has to be done here before the object can
be placed at its destination. Modifying message order seemed unviable;
this fix fiddles with the Levitation property in order to defer hero's
descent until after object handling is finished. Now same setup gives:
You drop a gray stone named The Heart of Ahriman.
A gray stone named The Heart of Ahriman hits the floor.
You float gently to the floor.
You see here a gray stone named The Heart of Ahriman.
From the newsgroup: Sunsword is ineffective against shades. It
gets a special bonus of double damage vs undead, but since it's not made
of silver it was only doing 1 point of damage against shades. Make the
bonus-vs-undead attribute override the silver-required criterion. (No
comparable handling for flimsy weapons against thick-skinned critters
this time.)
Extend rotouch_equipment() to cover all items in use, worn/carried/
invoked in addition to wielded. Done when you change alignment, change
shape, or catch lycanthropy. No-longer-touchable items inflict modest
damage; worn/wielded ones will be unworn/unwielded. For the shape change
and lycanthropy cases, unwieled weapons are also dropped. Other unworn
stuff stays in inventory, as do weapons for the alignment change case.
It ought to force off gloves if worn silver--or hypothetical
artifact--ring has become untouchable and gets unworn. Instead it just
curses the gloves, if necessary, so that there's some plausibility to
having the ring come off.
Make polymorphing or changing alignment perform a touch check (as is
done when catching lycanthropy) on wielded weapon(s) to see whether the
hero can still use them in his new form. Part [2 of 2] will update
retouch_equipment() to check all items in use rather than just weapon(s).
(A comment or two in part 1 already refers to expected behavior of part 2.)
Monster werecritters are vulnerable to silver when in human form as
well as when in beast form, but hero inflicted with lycanthropy was only
vulnerable while in beast form. Add pseudo-property Hate_silver to handle
that correctly. Also, add silver vulnerability to enlightenment feedback.
Lastly, hero vulnerable to silver had Con abused if hit by silver missile
but not when hit hand-to-hand; add an exercise() call to the latter.
From a bug report, trying
to invoke a wielded artifact after changing alignment resulted in "the
<artifact> evades your grasp" but it remained wielded, contradicting the
message. This adjusts the message in touch_artifact() if the object is
already in inventory, and adds retouch_object() to handle cases where
failing to be able to touch ought to force unwearing/unwielding.
The devteam feedback was to place casts in the code
in question.
This puts explicit casts on some code that was being
compiled into 'int64' then stuffed into smaller types with
VC2005.
When testing the spoteffects/drown hack I noticed that draining myself
with Stormbringer (toss up, get hit on head) while in iron golem form gave
messages about it drawing or draining life. (I'm sure that this has come
up before....) I've altered the artifact hit message rather than making
golems become resistant, although the opposite approach seems at least as
valid. The drain life spell uses different wording and isn't affected.
Be deliberately careful with copies taken of
oextra pointers and clear the pointer if it
truly is a redundant copy that will become
invalid if/when the original holder is deallocated.
move oattached and oname and other things that vary
the size of the obj structure into a separate
non-adjacent oextra structure, similar to what has
already been done for mextra. The obj structure
itself becomes a fixed size.
New macros:
#define ONAME(o) ((o)->oextra->oname)
#define OMID(o) ((o)->oextra->omid)
#define OMONST(o) ((o)->oextra->omonst)
#define OLONG(o) ((o)->oextra->olong)
#define OMAILCMD(o) ((o)->oextra->omailcmd)
#define has_oname(o) ((o)->oextra && ONAME(o))
#define has_omid(o) ((o)->oextra && OMID(o))
#define has_omonst(o) ((o)->oextra && OMONST(o))
#define has_olong(o) ((o)->oextra && OLONG(o))
#define has_omailcmd(o) ((o)->oextra && OMAILCMD(o))
changed macros:
has_name(mon) becomes has_mname(mon) to correspond.
The CVS repository was tagged with
NETHACK_PRE_OEXTRA
before commiting these, and
tagged with
NETHACK_POST_OEXTRA
immediately after. The diff
between those two tags is this oextra patch.
The associated mail daemon changes to use an oextra
structure instead of a hidden command located in the
name after the terminating NUL, have not been tried
or tested.
I don't know for sure what all the possible values of hittee passed to
Mb_hit() are, but this checks to see if it matches the name of the
mdef monster and forces the word "is" if it does.
The fix to prevent naming an unknown gray stone "the Heart of Ahriman"
from revealing whether the object was a luckstone was inadequate to prevent
using the same trick with "the Mitre of Holiness" to determine if an unknown
helmet was a helm of brilliance. (I don't know whether whoever figured out
the first one has realized the second yet; no one had mentioned it in the
newsgroup the last time I looked.) To get this right we need to check for
objects sharing the same set of shuffled descriptions in addition to testing
whether they have identical descriptions. Doing that meant reorganizing how
object shuffling is done, but it produces the same behavior as before.
Refine yesterday's change in how attempting to assign an artifact's
name to some object works: only check object descriptions for undiscovered
object types. Once you know that a particular gray stone is a flint stone,
you could name it "the Heart of Ahriman" as before the previous change.
Conversely, once you learn luck stones, you could give that name to any
other unknown gray stone. This restores the ability of a player to name
his elven broadsword such that some unsuspecting other player might find
"a runed broadsword named Stormbringer" in a bones file.
From the newsgroup: when you pick up a gray stone, you can determine
whether it is a luckstone by attempting to name it "the Heart of Ahriman".
Your "fingers slip" if it is, they don't if it isn't. That's way too
cheesy for my tastes. This patch will make the finger slipping occur for
any item that has the same description rather than just for the exact type.
Now you won't be able to name any type of gray stone "the Heart of Ahriman"
(nor an elven broadsword "Stormbringer"; however, assuming that you manage
to acquire a non-artifact runesword, you can still uselessly name it
"Orcrist" if you want).
