Do a bunch of proofreading fixes.

[ibg.git] / chapters / 12.rst

diff --git a/chapters/12.rst b/chapters/12.rst
index 4e8654ad071dc9891228bebe1f81f16824f8f24a..b22ae9368c8da2f7b75f182631880b38cd2b732b 100644 (file)
--- a/chapters/12.rst
+++ b/chapters/12.rst
@@ -52,7 +52,7 @@ could benefit from the effort. The product of this generosity takes the
 form of a library extension: the solution neatly packaged as a file that 
 other designers can incorporate into their source code. These files can 
 be found in the IF Archive: go to 
 form of a library extension: the solution neatly packaged as a file that 
 other designers can incorporate into their source code. These files can 
 be found in the IF Archive: go to 

-``http://mirror.ifarchive.org/indexes/if-archive.html`` and then select 
+http://mirror.ifarchive.org/indexes/if-archive.html and then select 

 "``.../infocom``", "``.../compilers``", "``.../inform6``", 
 "``.../library``", and "``.../contributions``". All of these files 
 contain Inform code. To use a library extension (also known as a library 
 "``.../infocom``", "``.../compilers``", "``.../inform6``", 
 "``.../library``", and "``.../contributions``". All of these files 
 contain Inform code. To use a library extension (also known as a library 


@@ -64,15 +64,14 @@ there are rules about where exactly this Include should be placed in
 your source code. It is not unusual to find other suggestions and 
 warnings.
 
 your source code. It is not unusual to find other suggestions and 
 warnings.
 

-To help us out of the disambiguation problem with the word TOILET, we 
-are going to use Neil Cerutti's extension ``pname.h``, which is designed 
-for situations precisely like this. First, we follow the link to the IF 
-archive and download the compressed file ``pname.zip``, which contains 
-two more files: ``pname.h`` and ``pname.txt``. We place these files in 
-the folder where we are currently developing our game or, if using the 
-environment we proposed in "Tools of the trade" on page 17, in the 
-``Inform\Lib\Contrib`` folder. The text file offers instructions about 
-installation and usage. Here we find a warning:
+To help us out of the disambiguation problem with the word TOILET, we are
+going to use Neil Cerutti's extension ``pname.h``, which is designed for
+situations precisely like this. First, we follow the link to the IF archive
+and download the compressed file ``pname.zip``, which contains two more
+files: ``pname.h`` and ``pname.txt``. We place these files in the folder
+where we are currently developing our game or, if using the environment we
+proposed in :doc:`02`, in the ``Inform\Lib\Contrib`` folder. The text file
+offers instructions about installation and usage. Here we find a warning:

 
   This version of pname.h is recommended for use only with version 6/10 
   of the Inform Library.
 
   This version of pname.h is recommended for use only with version 6/10 
   of the Inform Library.


@@ -108,14 +107,19 @@ instructions:
   #.  Add four lines near the head of the program (before you include 
       ``Parser.h``).
 
   #.  Add four lines near the head of the program (before you include 
       ``Parser.h``).
 

-      ``Replace MakeMatch;``
-      ``Replace Identical;``
-      ``Replace NounDomain;``
-      ``Replace TryGivenObject;``
+      .. code-block:: inform
+
+         Replace MakeMatch;
+         Replace Identical;
+         Replace NounDomain;
+         Replace TryGivenObject;

 
   #.  Include the ``pname.h`` header just after you include ``Parser.h``.
 
   #.  Include the ``pname.h`` header just after you include ``Parser.h``.

-      ``Include "Parser";``
-      ``Include "pname";``
+
+      .. code-block:: inform
+
+         Include "Parser";
+         Include "pname";

 
   #.  Add ``pname`` properties to those objects which require phrase 
       recognition.
 
   #.  Add ``pname`` properties to those objects which require phrase 
       recognition.


@@ -142,7 +146,7 @@ providing replacements for some standard routines.
 
   Include "Parser";
   Include "pname";
 
   Include "Parser";
   Include "pname";

-  !...
+  ...

 
 Now our source code is ready to benefit from the library package. How 
 does it work? We have acquired a new property -- ``pname`` -- which can 
 
 Now our source code is ready to benefit from the library package. How 
 does it work? We have acquired a new property -- ``pname`` -- which can 


@@ -151,21 +155,17 @@ be added to some of our objects, and which works pretty much like a
 property where we have a disambiguation problem. Let’s change the 
 relevant lines for the toilet door and the toilet key:
 
 property where we have a disambiguation problem. Let’s change the 
 relevant lines for the toilet door and the toilet key:
 

-.. todo::
-
-  Maybe specially highlight the lines using pname?
-

 .. code-block:: inform
 
   Object  toilet_door
     with  pname '.x' 'red' '.x' 'toilet' 'door',
           short_name [;
 .. code-block:: inform
 
   Object  toilet_door
     with  pname '.x' 'red' '.x' 'toilet' 'door',
           short_name [;

-          !...
+          ...

 
   Object  toilet_key "toilet key" benny
     with  pname '.x' 'toilet' 'key',
           article "the",
 
   Object  toilet_key "toilet key" benny
     with  pname '.x' 'toilet' 'key',
           article "the",

-          !...
+          ...

 
 while leaving the ``outside_of_toilet`` unchanged:
 
 
 while leaving the ``outside_of_toilet`` unchanged:
 


@@ -174,7 +174,7 @@ while leaving the ``outside_of_toilet`` unchanged:
   Object  outside_of_toilet "toilet" cafe
     with  name 'toilet' 'bath' 'rest' 'room' 'bathroom' 'restroom',
           before [;
   Object  outside_of_toilet "toilet" cafe
     with  name 'toilet' 'bath' 'rest' 'room' 'bathroom' 'restroom',
           before [;

-          !...
+          ...

 
 We are now using a new operator -- ``'.x'`` -- in our ``pname`` word 
 lists. explains
 
 We are now using a new operator -- ``'.x'`` -- in our ``pname`` word 
 lists. explains


@@ -186,7 +186,7 @@ and this makes the dictionary word ``'toilet'`` of lesser importance for
 these objects, so that at run-time players could refer to the DOOR or 
 TOILET DOOR or the KEY or TOILET KEY -- but not simply to the TOILET -- 
 when referring to either the door or the key. And, by leaving unchanged 
 these objects, so that at run-time players could refer to the DOOR or 
 TOILET DOOR or the KEY or TOILET KEY -- but not simply to the TOILET -- 
 when referring to either the door or the key. And, by leaving unchanged 

-the name property of the outside_of_toilet object – where there is also 
+the name property of the ``outside_of_toilet`` object – where there is also 

 another ``'toilet'`` entry -- the ``pname`` properties will tell the 
 interpreter to discard the key and the door as possible objects to be 
 considered when players refer just to TOILET. Looking at it in terms of 
 another ``'toilet'`` entry -- the ``pname`` properties will tell the 
 interpreter to discard the key and the door as possible objects to be 
 considered when players refer just to TOILET. Looking at it in terms of 


@@ -298,7 +298,7 @@ capability), is more local property variables:
           coffee_not_paid  false,          ! is Benny waiting to be paid?
           key_not_returned false,          ! is Benny waiting for the key?
           live [;
           coffee_not_paid  false,          ! is Benny waiting to be paid?
           key_not_returned false,          ! is Benny waiting for the key?
           live [;

-          !...
+          ...

 
 Now we are ready to tackle the ``Give`` action of the ``life`` property, 
 which deals with commands like GIVE THE KEY TO BENNY (in a moment, we'll 
 
 Now we are ready to tackle the ``Give`` action of the ``life`` property, 
 which deals with commands like GIVE THE KEY TO BENNY (in a moment, we'll 


@@ -338,27 +338,26 @@ statement as shorthand for:
 
   if (noun == costume) { whatever };
   if (noun == clothes) { whatever };
 
   if (noun == costume) { whatever };
   if (noun == clothes) { whatever };

-  !...
-
-We won't let players give away their clothes or their costume (yes, an 
-improbable action, but you never know). The toilet key and the coin are 
-successfully transferred. The property ``key_not_returned`` will be set 
-to true when we receive the toilet key from Benny (we have not coded 
-that bit yet), and now, when we give it back, it's reset to ``false``. 
-The ``move`` statement is in charge of the actual transfer of the object 
-from the player's inventory to Benny, and we finally display a 
-confirmation message. With the coin, we find a new statement: 
-``remove``. This extracts the object from the object tree, so that it 
-now has no parent. The effect is to make it disappear from the game 
-(though you are not destroying the object permanently -- and indeed you 
-could return it to the object tree using the ``move`` statement); as far 
-as the player is concerned, there isn’t a COIN to be found anywhere. The 
-``coffee_not_paid`` property will be set to true when Benny serves us 
-the cup of coffee (again, we’ll see that in a moment); now we reset it 
-to ``false``, which liberates the player from debt. This culminates with 
-the ``"..."`` print-and-return statement, telling the player that the 
-action was successful. In passing, remember that in "A homely 
-atmosphere" on page 131 we defined the counter such that PUT KEY ON 
+  ...
+
+We won't let players give away their clothes or their costume (yes, an
+improbable action, but you never know). The toilet key and the coin are
+successfully transferred. The property ``key_not_returned`` will be set to
+true when we receive the toilet key from Benny (we have not coded that bit
+yet), and now, when we give it back, it's reset to ``false``.  The ``move``
+statement is in charge of the actual transfer of the object from the
+player's inventory to Benny, and we finally display a confirmation
+message. With the coin, we find a new statement: ``remove``. This extracts
+the object from the object tree, so that it now has no parent. The effect
+is to make it disappear from the game (though you are not destroying the
+object permanently -- and indeed you could return it to the object tree
+using the ``move`` statement); as far as the player is concerned, there
+isn’t a COIN to be found anywhere. The ``coffee_not_paid`` property will be
+set to true when Benny serves us the cup of coffee (again, we’ll see that
+in a moment); now we reset it to ``false``, which liberates the player from
+debt. This culminates with the ``"..."`` print-and-return statement,
+telling the player that the action was successful. In passing, remember
+that in :ref:`homely-atmos` we defined the counter such that PUT KEY ON

 COUNTER is automatically translated into GIVE KEY TO BENNY .
 
 Why move the key to Benny but remove the coin instead? Once players 
 COUNTER is automatically translated into GIVE KEY TO BENNY .
 
 Why move the key to Benny but remove the coin instead? Once players