User:Tungtn/H4248 - Stop the Wizard of Yendor from stealing the current role's quest artifact

From NetHackWiki
Jump to navigation Jump to search

February 15, 2016 at 04:28:45

Below is what you submitted to The_DevTeam on Monday, February 15, 2016 at 04:28:45

The ID number for this message is '#H4248'

mailversion:

master:1.55

nhversion:

3.6.0

nhfrom:

Our 3.6.0 git - list branch and ref below

hardware:

Please describe your hardware.  Important items may include:
vendor
model
processor
amount of memory
amount of disk space

software:

branch NetHack-3.6.0
commit 592ae6972626c41c52100b14f1c77bb83323faf8

comments:

Aside: I'm looking forward to public issue tracker to submit things like this to, because bugs and feature suggestions to NetHack are in the public interest, and coordinating them in private runs counter to that.

As the title says, currently the Wizard of Yendor ("Rodney") will try to steal the player's quest artifact, in the same logic that makes him steal the Amulet and invocation items. This makes your current role's quest artifact the WORST artifact to rely on for powers or resistances, e.g. rangers DON'T want to rely on the Longbow of Diana for reflection. Many players simply leave their quest artifact on the ground because they'd never want to rely on it, specifically because Rodney can steal it. This makes e.g. rangers play less ranger-like, reducing role uniqueness.

This also encourages quest artifact wishing, which homogenizes the gameplay styles of different roles, since the available selection of quest artifacts is almost entirely independent of the role.

I and other players/developers have long suggested removing Rodney's ability to steal the current role's quest artifact, giving players more incentive to use the role-unique artifacts and thus increase gameplay variety across roles. This is in fact already the status quo in the popular dNetHack variant for exactly this reason, and is also the case in my own DynaHack variant. Here is a patch I just put together that makes this happen:

diff --git a/src/mhitu.c b/src/mhitu.c
index d8c85a1..399237a 100644
--- a/src/mhitu.c
+++ b/src/mhitu.c
@@ -1322,8 +1322,7 @@ register struct attack *mattk;
     case AD_SAMU:
         hitmsg(mtmp, mattk);
         /* when the Wiz hits, 1/20 steals the amulet */
-        if (u.uhave.amulet || u.uhave.bell || u.uhave.book || u.uhave.menorah
-            || u.uhave.questart) /* carrying the Quest Artifact */
+        if (u.uhave.amulet || u.uhave.bell || u.uhave.book || u.uhave.menorah)
             if (!rn2(20))
                 stealamulet(mtmp);
         break;
diff --git a/src/steal.c b/src/steal.c
index 4b5378d..3e0abfe 100644
--- a/src/steal.c
+++ b/src/steal.c
@@ -517,12 +517,6 @@ struct monst *mtmp;
     if (u.uhave.amulet) {
         real = AMULET_OF_YENDOR;
         fake = FAKE_AMULET_OF_YENDOR;
-    } else if (u.uhave.questart) {
-        for (otmp = invent; otmp; otmp = otmp->nobj)
-            if (is_quest_artifact(otmp))
-                break;
-        if (!otmp)
-            return; /* should we panic instead? */
     } else if (u.uhave.bell) {
         real = BELL_OF_OPENING;
         fake = BELL;

February 28, 2016 at 19:40:00

https://github.com/NetHack/NetHack/commit/850ed0cba623cb403122a7ab280402a83383e92d

address #H4247 & #4248 - theft of quest artifact

Two different reports complaining that having the Wizard steal the
hero's quest artifact is a bad thing.  This doesn't change that,
but it does make all quest artifacts become equal targets so that
wishing for other roles' artifacts doesn't offer such a safe way to
have whichever special attributes they provide.

Quest artifacts are actually higher priority targets for theft than
the Amulet.  I suspect that probably wasn't originally intended,
but I left things that way.  Taking quest artifacts leaves the hero
more vulnerable to future thefts, and once they're gone the Amulet
has priority over the invocation tools.

(tungtn: Note the complete absence of feedback on whether the issue had been seen by human eyes, the closing of the issue, and the fact that the issue is not resolved by the above commit.)