],
has supporter;
-That :prop:`before` property, superficially normal, actually conceals a
-little surprise. By now you should be entirely comfortable with using an
-object's :prop:`before` property to intercept an action directed at that
-object; for example, if the player types HIT COUNTER then the counter's
-:prop:`before` property is potentially able to intercept the resulting
-Attack action. However, the command PUT KEY ON COUNTER generates *two*
-actions. First, a PutOn action is offered to the key (effectively
-saying, do you want to be placed on top of the counter?); that’s the
-normal bit. And then the surprise: a Receive action is offered to the
-counter (effectively saying, are you happy to have the key placed on
-you?) Both actions have the same opportunity of returning :const:`false` to
-let the action continue, :const:`true` to prevent it.
-
-.. todo::
-
- There are a lot of actions here that are rendered in a typewriter font
- and others that are not. Should these ones that are not be promoted
- to having a typewriter font?
-
-The Receive action is generated by the library in the PutOnSub action
-handler, and also in InsertSub (so a command like PUT BIRD IN NEST sends a
-Receive to the nest object). There’s a matching LetGo, generated by the
-library from commands like TAKE KEY OFF COUNTER and REMOVE BIRD FROM
-NEST. Receive and LetGo are examples of what’s called a :term:`fake
-action`.
+That :prop:`before` property, superficially normal, actually conceals a
+little surprise. By now you should be entirely comfortable with using an
+object's :prop:`before` property to intercept an action directed at that
+object; for example, if the player types HIT COUNTER then the counter's
+:prop:`before` property is potentially able to intercept the resulting
+``Attack`` action. However, the command PUT KEY ON COUNTER generates *two*
+actions. First, a ``PutOn`` action is offered to the key (effectively
+saying, do you want to be placed on top of the counter?); that’s the normal
+bit. And then the surprise: a ``Receive`` action is offered to the counter
+(effectively saying, are you happy to have the key placed on you?) Both
+actions have the same opportunity of returning :const:`false` to let the
+action continue, :const:`true` to prevent it.
+
+The ``Receive`` action is generated by the library in the ``PutOnSub``
+action handler, and also in ``InsertSub`` (so a command like PUT BIRD IN
+NEST sends a Receive to the nest object). There’s a matching ``LetGo``,
+generated by the library from commands like TAKE KEY OFF COUNTER and REMOVE
+BIRD FROM NEST. ``Receive`` and ``LetGo`` are examples of what’s called a
+:term:`fake action`.
.. note::
In "William Tell" we defined the ``quiver``, way back in
:ref:`possessions`, as an ``open container``. As things stand, the player
can put *any* held object, however inappropriate, into it. We could have
- trapped the Receive action to ensure that arrows are the only acceptable
- contents (recollect that ``~~``, to be read as "not", turns true into
- false and vice versa):
+ trapped the ``Receive`` action to ensure that arrows are the only
+ acceptable contents (recollect that ``~~``, to be read as "not", turns
+ true into false and vice versa):
.. code-block:: inform
simple rejection message, just in case the player tries to order people
around.
-Which leaves us with the :prop:`daemon` bit. A daemon is a property normally
-used to perform some timed or repetitive action without the need of the
-player’s direct interaction; for example, machines which work by
-themselves, animals that move on their own, or people going about their
-business. More powerfully, a daemon may take notice of the player’s
-decisions at a particular moment, allowing for some interactive
-behaviour; this is, however, an advanced feature that we won't use in
-this example. A daemon gets a chance of doing something at the end of
-every turn, typically to (or with) the object to which it’s associated.
-In our example, the daemon triggers some sneers and nasty comments from
-the customers once our hero comes out of the toilet dressed in Captain
-Fate’s costume.
+Which leaves us with the :prop:`daemon` bit. A daemon is a property
+normally used to perform some timed or repetitive action without the need
+of the player’s direct interaction; for example, machines which work by
+themselves, animals that move on their own, or people going about their
+business. More powerfully, a daemon may take notice of the player’s
+decisions at a particular moment, allowing for some interactive behaviour;
+this is, however, an advanced feature that we won't use in this example. A
+daemon gets a chance of doing something at the end of every turn, typically
+to (or with) the object to which it’s associated. In our example, the
+daemon triggers some sneers and nasty comments from the customers once our
+hero comes out of the toilet dressed in Captain Fate’s costume.
To code a daemon, you need to do three things:
complaining. Because Benny also has an :attr:`animate` attribute, the
interpreter would normally intercept a TAKE KEY action with "That seems
to belong to Benny"; however, the same wouldn't apply to other commands
-like TOUCH KEY and TASTE KEY . So, to prevent any interaction with the
+like TOUCH KEY and TASTE KEY. So, to prevent any interaction with the
key while it’s in Benny’s pockets, we define a :prop:`before` property.
.. code-block:: inform
projects / ibg.git / blobdiff