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
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
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::
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
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
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.