Merge pull request #169 from erkyrath/index-tidying-8

Next round of indexing, part 5

resources/Documentation/Examples/Anchorite.txt

@@ -5,7 +5,7 @@ Index: GET DOWN and DOWN understood as EXIT
 Description: By default, Inform understands ``GET OFF``, ``GET UP``, or ``GET OUT`` when the player is sitting or standing on an enterable object. We might also want to add ``GET DOWN`` and ``DOWN`` as exit commands, though.
 For: Z-Machine
 
-^^{>GET: GET DOWN and DOWN understood as EXIT}
+^^{>GET: (GET DOWN) and (DOWN) understood as (EXIT)+commandpart+}
 
 With ``GET DOWN``, we can replace the whole command, which will not interfere with the normal function of the ``TAKE`` verb, or allow the player to attempt to ``GET`` any other directions:
 

resources/Documentation/Examples/BattleOfRidgefield.txt

@@ -5,7 +5,9 @@ Index: Death message replaced
 Description: Completely replacing the endgame text and stopping the game without giving the player a chance to restart or restore.
 For: Z-Machine
 
-^^{end of story} ^^{death} ^^{losing the story}
+^^{end of story: not offering final question options}
+^^{death: not offering final question options}
+^^{losing the story: not offering final question options}
 
 Occasionally, a piece of IF is sufficiently serious that it feels bathetic to offer the player the usual restore-restart-undo-quit options at the end. The following would replace ``*** You have died ***`` with a centered epitaph, then quit the game when the player hits a key.
 

resources/Documentation/Examples/BigSkyCountry.txt

@@ -5,7 +5,10 @@ Index: Resuming play after an accidental death
 Description: Allowing the player to continue play after a fatal accident, but penalising them by scattering their possessions around the game map.
 For: Z-Machine
 
-^^{Resuming play after an accidental death}
+^^{when play ends+rb+} ^^{rules: run at end of story}
+^^{end of story: bringing the player back from death}
+^^{death: bringing the player back from death}
+^^{losing the story: bringing the player back from death}
 
 Some older games allowed the player to be resurrected after a death, but punished them by distributing his possessions far and wide. Here we emulate that effect.
 

resources/Documentation/Examples/BikiniAtoll.txt

@@ -5,7 +5,8 @@ Index: Banner printing at appropriate times
 Description: Delaying the banner for later.
 For: Z-Machine
 
-^^{banner text}
+^^{banner text} ^^{when play begins+rb+: printing the banner text+activity+}
+^^{initial state of the world: delaying the banner text}
 
 	{*}"Bikini Atoll" by Edward Teller
 

resources/Documentation/Examples/Blackout.txt

@@ -5,7 +5,9 @@ Index: Filtering text output in room names
 Description: Filtering the names of rooms printed while in darkness.
 For: Z-Machine
 
-^^{Filtering text output in room names}
+^^{text: replacing parts of a text}
+^^{characters (letters): replacing in text} ^^{regular expressions} ^^{text: regular expressions}
+^^{darkness: printing the name of a dark room+activity+} ^^{names: printing the name of a dark room+activity+} ^^{rooms+kind+: name of a dark room}
 
 In this example, we want the names of rooms to be asterisked out if the player wanders around without the benefit of a candle. We can do this by treating the room names as text, then replacing every letter:
 

resources/Documentation/Examples/Blankness.txt

@@ -5,7 +5,9 @@ Index: Blanking the status line before play
 Description: Emptying the status line during the first screen of the game.
 For: Z-Machine
 
-^^{Blanking the status line before play}
+^^{status line}
+^^{left hand status line (- text)+glob+} ^^{right hand status line (- text)+glob+}
+^^{virtual machine: starting the virtual machine+activity+}
 
 Occasionally we want to print something as our first screen and then pause the game. By default, Inform will print a rather odd status line, with ``You`` on the left side and ``0`` on the right. This is because the left hand status line is set to display the location, but (because we're not done with the when-play-begins rules) the player has not yet even been moved to a room.
 

resources/Documentation/Examples/Blink.txt

@@ -5,7 +5,8 @@ Index: Creating our own text variations rules
 Description: Making a `by atmosphere` token, allowing us to design our own text variations such as `"[one of]normal[or]gloomy[or]scary[by atmosphere]"`.
 For: Z-Machine
 
-^^{Creating our own text variations rules}
+^^{I6: inclusions: phrase elements}
+^^{text substitutions: defining: segmented} ^^{defining: text substitutions: segmented}
 
 Suppose we are writing a game in which the mood of the piece changes, and we would like to have lots of descriptions that vary according to its current state. We might in that case want to create our own `"[by atmosphere]"` token, to control text variations, like this:
 

resources/Documentation/Examples/Cavetroll.txt

@@ -5,6 +5,7 @@ Index: Modifying and re-parsing an entered command
 Description: Determining that the command the player typed is invalid, editing it, and re-examining it to see whether it now reads correctly.
 For: Z-Machine
 
+^^{regular expressions: in the player's command} ^^{text: regular expressions}
 ^^{reading a command+activity+: to modify the player's command} ^^{understanding: modifying the player's command}
 
 Novice players of interactive fiction, unfamiliar with its conventions, will often try to add extra phrases to a command that the game cannot properly parse: ``HIT DOOR WITH FIST``, for instance, instead of ``HIT DOOR``.

resources/Documentation/Examples/ChanelVersion1-G.txt

@@ -5,7 +5,7 @@ Index: HTML-style italic and boldface tags
 Description: Making paired italic and boldface tags like those used by HTML for web pages.
 For: Glulx
 
-^^{HTML-style italic and boldface tags}
+^^{fonts: italic / bold / roman}
 
 HTML uses angled brackets to achieve effects, and places italicised text between <i> and </i> tags; and similarly boldface between <b> and </b>. We can mimic this very easily by setting each up as a segmented substitution:
 

resources/Documentation/Examples/CornerOfNoAndWhere.txt

@@ -5,7 +5,9 @@ Index: Status line with centered text, the hard way
 Description: A status line which has only the name of the location, centered.
 For: Z-Machine
 
-^^{Status line with centered text, the hard way}
+^^{kits (I6 code): including sections of I6}
+^^{I6: inclusions: long sections of code}
+^^{status line}
 
 Making major changes to display features, such as the construction of the status line, sometimes requires that we rely on Inform 6 in bulk; here is how we might produce the Trinity-style status line, with the location centered at the top center of the screen.
 

resources/Documentation/Examples/Fido.txt

@@ -5,7 +5,10 @@ Index: Name of a dog set by the player
 Description: A dog the player can name and un-name at will.
 For: Z-Machine
 
-^^{Name of a dog set by the player}
+^^{names: selected by player}
+^^{text: replacing parts of a text}
+^^{punctuation: removing from player's command}
+^^{topic understood (- snippet)+glob+}
 
 Suppose we'd like to have a dog which the player is allowed to name himself. We'd like to deal correctly with both ``NAME THE DOG FIDO`` and ``NAME THE DOG "FIDO"`` so we'll also need to strip quotation marks out of the command. We can do this as follows:
 

resources/Documentation/Examples/Finality.txt

@@ -5,7 +5,11 @@ Index: UNDO not mentioned in the final question
 Description: Not mentioning ``UNDO`` in the final set of options.
 For: Z-Machine
 
-^^{UNDO not mentioned in the final question}
+^^{end of story: not offering (UNDO) option+commandpart+}
+^^{death: not offering (UNDO) option+commandpart+}
+^^{losing the story: not offering (UNDO) option+commandpart+}
+^^{>UNDO: not offering at end}
+^^{|Final Question Options: Table of Final Question Options} ^^{|Table of Final Question Options}
 
 By default, Inform reminds the player that they have the option of typing ``UNDO`` after a story-ending action. This is generally good practice, especially for the sake of novice players who might not be aware of this possibility otherwise, and might be frustrated by a loss they could easily step back from.
 

resources/Documentation/Examples/FrozenAssets.txt

@@ -5,6 +5,7 @@ Index: BUY command and a system of money
 Description: A treatment of money which keeps track of how much the player has on them, and a ``BUY`` command which lets them go shopping.
 For: Z-Machine
 
+^^{money (implementing)}
 ^^{buying+action+: a system of money}
 
 In our brave new world, everything will have a price, so we had better spell this out.

resources/Documentation/Examples/IgpayAtinlay.txt

@@ -5,7 +5,7 @@ Index: Pig Latin for the player's commands
 Description: A pig Latin filter for the player's commands.
 For: Z-Machine
 
-^^{Pig Latin for the player's commands}
+^^{text: replacing parts of a text} ^^{characters (letters): replacing in text} ^^{regular expressions: in the player's command} ^^{text: regular expressions}
 
 For the sake of argument, suppose we want to parrot back all the player's commands in pig Latin:
 

resources/Documentation/Examples/Jamaica1688.txt

@@ -5,7 +5,7 @@ Index: Changing the final question after victory
 Description: Adding a feature to the final question after victory, so that the player can choose to reveal notes about items in the game.
 For: Z-Machine
 
-^^{|Table of Final Question Options}
+^^{|Final Question Options: Table of Final Question Options} ^^{|Table of Final Question Options}
 
 The options offered to the player at the end of the game are listed in the `Table of Final Question Options`, which means that we can add to them simply by continuing the table; what's more, the table gives us the opportunity to create a `final response rule`, a rule that the game should follow in order to parse the player's input at this point.
 

resources/Documentation/Examples/Lemonade.txt

@@ -6,6 +6,8 @@ Description: Containers for liquid which keep track of how much liquid they are
 For: Z-Machine
 
 ^^{liquids (implementing): containers with measured contents}
+^^{containers+kind+: liquids in containers}
+^^{units of measure: arithmetic} ^^{calculation: arithmetic with units}
 
 Liquids, and all substances that can be mixed or broken off in partial amounts, pose a challenge to model in interactive fiction. The following example is a simple one, but adequate for many scenarios.
 

resources/Documentation/Examples/MinimalMovement.txt

@@ -5,7 +5,7 @@ Index: GO equivalent to GO OUT
 Description: Supplying a default direction for ``GO``, so that ``LEAVE``, ``GO``, etc., are always interpreted as ``OUT``.
 For: Z-Machine
 
-^^{>GO: equivalent to GO OUT}
+^^{>GO: equivalent to (GO OUT)+commandpart+}
 
 Sometimes it would be nice to respond a little more sensitively to a vague command such as ``LEAVE`` – converting it, perhaps, to a ``GO OUT`` command.
 

resources/Documentation/Examples/Misadventure.txt

@@ -5,7 +5,7 @@ Index: GO TO ROOM command
 Description: A going by name command which does respect movement rules, and accepts names of rooms as commands.
 For: Z-Machine
 
-^^{>GO: GO TO ROOM command}
+^^{>GO: (GO TO ROOM) command+commandpart+}
 
 The original Adventure allowed the player to type the names of rooms in order to move to them, and it is now not too difficult for us to do the same. Adventure restricted this option to adjacent rooms, but we might want to be a bit more flexible, so we will accept any room:
 

resources/Documentation/Examples/MoneyForNothing.txt

@@ -5,7 +5,8 @@ Index: OFFER price FOR command allowing player to bargain
 Description: An ``OFFER PRICE FOR`` command, allowing the player to bargain with a flexible seller.
 For: Z-Machine
 
-^^{OFFER price FOR command allowing player to bargain}
+^^{money (implementing): bargaining with (OFFER ... FOR)+commandpart+}
+^^{characters (people): bargaining with}
 
 	{*}"Money for Nothing"
 

resources/Documentation/Examples/MrBurnsRepast.txt

@@ -5,7 +5,8 @@ Index: Fish of ambiguous species
 Description: Letting the player guess types for an unidentifiable fish.
 For: Z-Machine
 
-^^{Fish of ambiguous species}
+^^{regular expressions: in the player's command} ^^{text: regular expressions}
+^^{reading a command+activity+: to extract a text value}
 
 Suppose we have an unhappily mutated fish that the player can refer to by any of a number of species names, or any word followed by -fish. We want to reject these commands, but preserve a memory of what the player last tried to call the thing:
 

resources/Documentation/Examples/Nameless.txt

@@ -5,7 +5,7 @@ Index: ASK someone ABOUT an object the same as SHOW
 Description: ASKing someone about an object rather than about a topic.
 For: Z-Machine
 
-^^{asking (actor) about+action+: an object the same as SHOW}
+^^{asking (actor) about+action+: an object the same as (SHOW)+commandpart+}
 
 By default, ``ASK SOMEONE ABOUT ...`` applies only to a text token. We might want also to offer the player the option of asking characters about pieces of physical evidence. This example implements an ``ASK PERSON ABOUT THING`` command that is mostly synonymous with ``SHOW``, with the added nuance that the player can ask about things that are not currently visible, as long as they have encountered them at some time in the past.
 

resources/Documentation/Examples/NickelAndDimed.txt

@@ -5,6 +5,7 @@ Index: BUY command and money, complete with denominations
 Description: A more intricate system of money, this time keeping track of the individual denominations of coins and bills, specifying what gets spent at each transaction, and calculating appropriate change.
 For: Z-Machine
 
+^^{money (implementing): with denominations}
 ^^{buying+action+: money, complete with denominations}
 
 Typically games which keep track of the player's wealth need only do so as an abstract number, but occasionally it becomes useful to represent money as physical coins and bills. Here is an example that does exactly that:

resources/Documentation/Examples/Northstar.txt

@@ -5,7 +5,9 @@ Index: ASK person TO do something, understood
 Description: Making Inform understand ``ASK JOSH TO TAKE INVENTORY`` as ``JOSH, TAKE INVENTORY``. This requires us to use a regular expression on the player's command, replacing some of the content.
 For: Z-Machine
 
-^^{asking (actor) to try+action+: understanding ASK ACTOR TO}
+^^{regular expressions: in the player's command} ^^{text: regular expressions}
+^^{reading a command+activity+: to modify the player's command} ^^{understanding: modifying the player's command}
+^^{asking (actor) to try+action+: understanding (ASK ACTOR TO)+commandpart+}
 
 Most of the time, Inform understands commands to other characters when they take the form ``JOSH, TAKE INVENTORY`` or ``JOAN, WEAR THE ARMOR``. But novice players might also try commands of the form ``ASK JOSH TO TAKE INVENTORY`` or ``ORDER JOAN TO WEAR THE ARMOR``.
 

resources/Documentation/Examples/OwensLaw.txt

@@ -5,7 +5,7 @@ Index: GO OUT and GO IN determine most appropriate direction if none is defined
 Description: ``OUT`` always means "move to an outdoors room, or else to a room with more exits than this one has"; ``IN`` always means the opposite.
 For: Z-Machine
 
-^^{>GO: GO OUT and GO IN determine most appropriate direction if none is defined}
+^^{>GO: (GO OUT) and (GO IN) determine most appropriate direction if none is defined+commandpart+}
 
 Suppose we want the game to interpret ``GO OUT`` as "move towards an outdoors room, or towards a room with more exits than the current room", while ``GO IN`` means "move toward a room with fewer exits, or towards an indoors room". Thus going in repeatedly within a building would lead towards dead-ends, while going out repeatedly would lead towards the center of the building and then towards an exit to the outside world.
 

resources/Documentation/Examples/Polarity.txt

@@ -5,7 +5,7 @@ Index: GO BACK command
 Description: A "go back" command that keeps track of the direction from which the player came, and sends them back.
 For: Z-Machine
 
-^^{>GO: GO BACK command}
+^^{>GO: (GO BACK) command+commandpart+}
 
 The main trick of this is always to record where the player has gone when they have just moved.
 

resources/Documentation/Examples/SafariGuide.txt

@@ -5,7 +5,7 @@ Index: GO TO ROOM with automatic door-handling en route
 Description: The same functionality, but making the player continue to move until they reach their destination or a barrier, handling all openable doors on the way.
 For: Z-Machine
 
-^^{>GO: GO TO ROOM command: with automatic door-handling en route}
+^^{>GO: (GO TO ROOM) command+commandpart+: with automatic door-handling en route}
 
 The foregoing example moves the player one location towards his destination, and requires that rooms have been visited before. But suppose we wanted to be a bit more lenient about movement, and let the player make as many steps as necessary per turn. We will also show consideration about doors, using the extension `Locksmith by Emily Short`. (Now every time the code attempts opening a door, unlocking rules will also be invoked.)
 

resources/Documentation/Examples/Savannah.txt

@@ -5,7 +5,8 @@ Index: POUR that pours liquid on a fire
 Description: Using the liquid implementation demonstrated in Lemonade for putting out fires.
 For: Z-Machine
 
-^^{POUR that pours liquid on a fire}
+^^{liquids (implementing): (POUR) command+commandpart+}
+^^{containers+kind+: liquids in containers}
 
 Here we build very slightly on the existing liquid implementation to add a puzzle where the player puts out a fire with a bucket of water. Most of the liquid implementation remains the same as before, but now we understand the names of containers according to the liquids they contain.
 

resources/Documentation/Examples/UncommonGround.txt

@@ -5,7 +5,8 @@ Index: Creating our own text variations rules, part two
 Description: Making a "by viewpoint" token, allowing us to design our own text variations such as "[show to yourself]quaint[to Lolita]thrilling[to everyone else]squalid[end show]" depending on the identity of the player at the moment.
 For: Z-Machine
 
-^^{Creating our own text variations rules, part two}
+^^{I6: inclusions: phrase elements}
+^^{text substitutions: defining: segmented} ^^{defining: text substitutions: segmented}
 
 A slightly more challenging case than the "by atmosphere" example is one in which we want to create text variations depending on the identity of our player character.
 

resources/Documentation/Examples/Wonderland.txt

@@ -5,7 +5,7 @@ Index: GO UP and GO DOWN determined by room altitude
 Description: Hiking Mount Rainier, with attention to which locations are higher and which lower than the present location.
 For: Z-Machine
 
-^^{>GO: GO UP and GO DOWN determined by room altitude}
+^^{>GO: (GO UP) and (GO DOWN) determined by room altitude+commandpart+}
 
 Suppose we have a landscape with a great deal of up and down variation, where ``GO UP`` and ``GO DOWN`` will be significant almost everywhere, and specifying them all individually a tremendous pain:
 

resources/Documentation/Examples/Xerxes.txt

@@ -5,7 +5,8 @@ Index: AMUSING menu shown at the endgame
 Description: Offering the player a menu of things to read after winning the game.
 For: Z-Machine
 
-^^{AMUSING menu shown at the endgame}
+^^{when play ends+rb+: amusing a victorious player+activity+}
+^^{>AMUSING}
 
 Building a menu is moderately tedious, so we will rely on the standard menu extensions provided. Thus:
 

resources/Documentation/The Recipe Book.md

@@ -911,7 +911,9 @@ If that's not enough, we can get a comprehensive view of everything that happens
 
 ## Modifying Existing Commands
 
-^^{actions: processing sequence}^^{actions: rules for actions found in rulebooks}^^{rules: for actions found in rulebooks}^^{rulebooks: for actions}^^{before (action)+rb+: in action processing sequence} ^^{rules: before rules}^^{instead of (action)+rb+: in action processing sequence} ^^{rules: instead rules}^^{after (action)+rb+: in action processing sequence} ^^{rules: after rules}^^{check (action)+rb+}^^{carry out (action)+rb+}^^{report (action)+rb+}^^{(instead), to stop the action+sourcepart+}^^{rules: removing}^^{rules: replacing}^^{extensions: Inform 6 template layer}^^{Inform 6 inclusions: Inform 6 template layer}^^{templates: Inform 6 template layer}
+^^{actions: processing sequence}^^{actions: rules for actions found in rulebooks}^^{rules: for actions found in rulebooks}^^{rulebooks: for actions}^^{before (action)+rb+: in action processing sequence} ^^{rules: before rules}^^{instead of (action)+rb+: in action processing sequence} ^^{rules: instead rules}^^{after (action)+rb+: in action processing sequence} ^^{rules: after rules}^^{check (action)+rb+}^^{carry out (action)+rb+}^^{report (action)+rb+}^^{(instead), to stop the action+sourcepart+}^^{rules: removing}^^{rules: replacing}
+^^{extensions: I6 kit code}^^{I6: replacing kit code}
+
 Much of the rest of this chapter discusses the behaviour of specific commands in Inform's command library, and how we might change and build on these. This section is instead an overview of the general principles: where and how can one intervene?
 
 Whenever we are dealing with actions, the Actions Index is likely to be useful: it lists all the actions currently implemented, whether in our own source or in extensions or the Standard Rules, and lists the rules pertaining to each.