sortloot vs gems

Some object classes (such as armor and weapons) are split into
"subclasses" when sortloot applies an ordering (for armor, all helms,
then all gloves, then all boots, and so on).  Give gem class subsets.
Simple (1) valueable gem, (2) worthless glass, (3) gray stone, (4) rock
would give away information; instead, factor in discovery state and use
(1) unseen gems and glass ("gem")
(2) seen but undiscovered gems and glass ("blue gem"),
(3) discovered gems ("sapphire"),
(4) discovered glass ("worthless pieced of blue glass"),
(5) unseen gray stones and rocks ("stone"),
(6) seen but undiscovered gray stones ("gray stone"),
(7) discovered gray stones ("touchstone"),
(8) seen rocks ("rock").
If everything happens to be identified, the simpler ordering happens
(via 3, 4, 7, and 8) because the other subsets will be empty.

diff --git a/doc/fixes36.2 b/doc/fixes36.2
index 320d6288e25bc251c8335b43134f9d79725bf3f3..beeed33a73f82c38570371d46c64a74a0d47d25d 100644 (file)
--- a/doc/fixes36.2
+++ b/doc/fixes36.2
@@ -1,4 +1,4 @@
-$NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.220 $ $NHDT-Date: 1546465283 2019/01/02 21:41:23 $
+$NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.221 $ $NHDT-Date: 1546467443 2019/01/02 22:17:23 $
 
 This fixes36.2 file is here to capture information about updates in the 3.6.x
 lineage following the release of 3.6.1 in April 2018. Please note, however,
@@ -488,6 +488,11 @@ early level traps are sometimes covered by the remains of fake players
 fake player characters resist Conflict
 when inside a shop, far-look now includes shop prices for items marked as
        having been seen up close
+when sortloot is enabled, gems are grouped in subsets (1) unseen gems and
+       glass, (2) seen but unidentified gems and glass, (3) identified gems,
+       (4) identified glass, (5) unseen stones (includes unseen rocks),
+       (6) seen but unidentified gray stones, (7) identified gray stones,
+       and (8) seen rocks (IDed/unIDed not applicable)
 
 
 NetHack Community Patches (or Variation) Included

diff --git a/src/invent.c b/src/invent.c
index 7b1c1537843c0de643dd0049f26b4d1fe8c65887..c28a2120d3ceef24d49124f3d0db70fba692b33c 100644 (file)
--- a/src/invent.c
+++ b/src/invent.c
@@ -1,4 +1,4 @@
-/* NetHack 3.6 invent.c        $NHDT-Date: 1545946249 2018/12/27 21:30:49 $  $NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.247 $ */
+/* NetHack 3.6 invent.c        $NHDT-Date: 1546467443 2019/01/02 22:17:23 $  $NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.248 $ */
 /* Copyright (c) Stichting Mathematisch Centrum, Amsterdam, 1985. */
 /*-Copyright (c) Derek S. Ray, 2015. */
 /* NetHack may be freely redistributed.  See license for details. */
@@ -52,7 +52,7 @@ static int lastinvnr = 51; /* 0 ... 51 (never saved&restored) */
  */
 static char venom_inv[] = { VENOM_CLASS, 0 }; /* (constant) */
 
-/* sortloot() classification; called at most once for each object sorted  */
+/* sortloot() classification; called at most once [per sort] for each object */
 STATIC_OVL void
 loot_classify(sort_item, obj)
 Loot *sort_item;
@@ -71,6 +71,7 @@ struct obj *obj;
     const char *classorder;
     char *p;
     int k, otyp = obj->otyp, oclass = obj->oclass;
+    boolean seen, discovered = objects[otyp].oc_name_known ? TRUE : FALSE;
 
     /*
      * For the value types assigned by this classification, sortloot()
@@ -78,6 +79,7 @@ struct obj *obj;
      */
     if (!Blind)
         obj->dknown = 1; /* xname(obj) does this; we want it sooner */
+    seen = obj->dknown ? TRUE : FALSE,
     /* class order */
     classorder = flags.sortpack ? flags.inv_order : def_srt_order;
     p = index(classorder, oclass);
@@ -120,7 +122,7 @@ struct obj *obj;
                           : !is_pole(obj) ? 5 : 6);
         break;
     case TOOL_CLASS:
-        if (obj->dknown && objects[otyp].oc_name_known
+        if (seen && discovered
             && (otyp == BAG_OF_TRICKS || otyp == HORN_OF_PLENTY))
             k = 2; /* known pseudo-container */
         else if (Is_container(obj))
@@ -164,6 +166,35 @@ struct obj *obj;
             break;
         }
         break;
+    case GEM_CLASS:
+        /*
+         * Normally subclass takes priority over discovery status, but
+         * that would give away information for gems (assuming we'll
+         * group them as valuable gems, next glass, then gray stones,
+         * and finally rocks once they're all fully identified).
+         *
+         * Order:
+         *  1) unseen gems and glass ("gem")
+         *  2) seen but undiscovered gems and glass ("blue gem"),
+         *  3) discovered gems ("sapphire"),
+         *  4) discovered glass ("worthless pieced of blue glass"),
+         *  5) unseen gray stones and rocks ("stone"),
+         *  6) seen but undiscovered gray stones ("gray stone"),
+         *  7) discovered gray stones ("touchstone"),
+         *  8) seen rocks ("rock").
+         */
+        switch (objects[obj->otyp].oc_material) {
+        case GEMSTONE:
+            k = !seen ? 1 : !discovered ? 2 : 3;
+            break;
+        case GLASS:
+            k = !seen ? 1 : !discovered ? 2 : 4;
+            break;
+        default: /* MINERAL */
+            k = !seen ? 5 : (obj->otyp != ROCK) ? (!discovered ? 6 : 7) : 8;
+            break;
+        }
+        break;
     default:
         /* other classes don't have subclasses; we assign a nonzero
            value because sortloot() uses 0 to mean 'not yet classified' */
@@ -172,9 +203,9 @@ struct obj *obj;
     }
     sort_item->subclass = (xchar) k;
     /* discovery status */
-    k = !obj->dknown ? 1 /* unseen */
-        : (objects[otyp].oc_name_known || !OBJ_DESCR(objects[otyp])) ? 4
-          : (objects[otyp].oc_uname)? 3 /* named (partially discovered) */
+    k = !seen ? 1 /* unseen */
+        : (discovered || !OBJ_DESCR(objects[otyp])) ? 4
+          : (objects[otyp].oc_uname) ? 3 /* named (partially discovered) */
             : 2; /* undiscovered */
     sort_item->disco = (xchar) k;
 }