Add a bunch of autogenerated index entries.
[ibg.git] / chapters / 06.rst
index 603663d440432167be10a0b434df032c3ccf13b0..c0cd6dafc28f22dfc0dd518068cbbad196bbfa86 100644 (file)
@@ -155,9 +155,9 @@ pieces:
 
      Why not do that with the player?  Because the object which represents
      the player is defined by the library (rather than as part of our
-     game), and actually has an internal ID of ``selfobj``; :var:`player`
-     is a variable whose value is that identifier.  Rather than worry all
-     about this, it's easier to use the ``move`` statements.
+     game), and actually has an internal ID of :obj:`selfobj`;
+     :var:`player` is a variable whose value is that identifier.  Rather
+     than worry all about this, it's easier to use the ``move`` statements.
 
   There's one other task associated with the quiver; it's an article of
   clothing which Wilhelm is "wearing", a state denoted by the attribute
@@ -172,6 +172,10 @@ pieces:
   quiver ~worn`` -- read that as "give the quiver not-worn"; Inform often
   uses ``~`` to mean "not".)
 
+.. Generated by autoindex
+.. index::
+   pair: description; library property
+
 * If the player types EXAMINE ME, the interpreter displays the
   :prop:`description` property of the :var:`player` object.  The default
   value is "As good-looking as ever", a bit of a cliché in the world of
@@ -366,16 +370,22 @@ the first :prop:`before` we met looked like this::
        return true;
    ],
 
-The role of that original :prop:`before` was to intercept ``Listen``
+.. Generated by autoindex
+.. index::
+   pair: Examine; library action
+   pair: Listen; library action
+
+The role of that original :prop:`before` was to intercept :act:`Listen`
 actions, while leaving all others well alone.  The role of the
 :prop:`before` in the ``Prop`` class is broader: to intercept (a)
-``Examine`` actions, and (b) all the rest.  If the action is ``Examine``,
-then the ``return false`` statement means that the action carries on.  If
-the action is ``default`` -- none of those explicitly listed, which in this
-instance means *every* action apart from ``Examine`` -- then the
-``print_ret`` statement is executed, after which the interpreter does
-nothing further.  So, a ``Prop`` object can be EXAMINEd, but any other
-action addressed to it results in a "no need to worry" message.
+:act:`Examine` actions, and (b) all the rest.  If the action is
+:act:`Examine`, then the ``return false`` statement means that the action
+carries on.  If the action is ``default`` -- none of those explicitly
+listed, which in this instance means *every* action apart from
+:act:`Examine` -- then the ``print_ret`` statement is executed, after which
+the interpreter does nothing further.  So, a ``Prop`` object can be
+EXAMINEd, but any other action addressed to it results in a "no need to
+worry" message.
 
 That message is also more involved than anything we've so far displayed.
 The statement which produces it is::
@@ -410,6 +420,10 @@ The interesting things that this statement demonstrates are:
   display the following object's internal ID, is called a :term:`print
   rule`.
 
+.. Generated by autoindex
+.. index::
+   pair: self; library variable
+
 * There's a library variable :var:`self` which always contains the internal
   ID of the current object, and is really convenient when using a
   ``Class``.  By using this variable in our ``print_ret`` statement, we
@@ -436,6 +450,11 @@ would be a waste of time.
 A class for furniture
 ---------------------
 
+.. Generated by autoindex
+.. index::
+   single: NPC
+   pair: static; library attribute
+
 The last class for now -- we'll talk about the ``Arrow`` and ``NPC``
 classes in the next chapter -- is for furniture-like objects.  If you label
 an object with the :attr:`static` attribute, an attempt to TAKE it results
@@ -464,10 +483,14 @@ intercepting four actions; we *could* have written the property like this::
        PushDir: print_ret (The) self, " is too heavy for that.";
    ],
 
+.. Generated by autoindex
+.. index::
+   pair: PushDir; library action
+
 but since we're giving exactly the same response each time, it's better to
-put all of those actions into one list, separated by commas.  ``PushDir``,
-if you were wondering, is the action triggered by a command like PUSH THE
-TABLE NORTH.
+put all of those actions into one list, separated by commas.
+:act:`PushDir`, if you were wondering, is the action triggered by a command
+like PUSH THE TABLE NORTH.
 
 Incidentally, another bonus of defining classes like these is that you can
 probably reuse them in your next game.