Merge pull request #144 from erkyrath/index-tidy-2

Improvements to General Index (part 1)

inbuild/supervisor-module/Chapter 7/General Index.w

@@ -590,6 +590,7 @@ int Indexes::sort_comparison(const void *ent1, const void *ent2) {
 	for (int i=0; i<NL; i++) {
 		index_lemma *il = lemma_list[i];
 		if ((just_examples) && (il->example_index_status == 0)) continue;
+		if ((!just_examples) && (il->example_index_status == 2)) continue;
 		inchar32_t incipit = Str::get_first_char(il->sorting_key);
 		if (Characters::isalpha(incipit)) incipit = Characters::toupper(incipit);
 		else incipit = '#';

resources/Documentation/Examples/3AM.txt

@@ -5,6 +5,8 @@ Index: SHAKE command
 Description: A shake command which agitates soda and makes items thump around in boxes.
 For: Z-Machine
 
+^^{SHAKE command}
+
 	{*}"3 AM"
 	
 	Understand "shake [something preferably held]" as shaking.

resources/Documentation/Examples/AARPGnosis.txt

@@ -5,6 +5,8 @@ Index: Encyclopedia set
 Description: An Encyclopedia set which treats volumes in the same place as a single object, but can also be split up.
 For: Z-Machine
 
+^^{Encyclopedia set}
+
 Suppose we have a complete Encyclopedia in our game. The player is allowed to pick up the whole set (there must not be too many volumes), but also to do things with individual volumes, and indeed to scatter these volumes all over the place. Putting a volume back in the same place as the rest of the Encyclopedia should, however, restore it to the collective. We will start out by defining general rules for collectives like this:
 
 	{*}"AARP-Gnosis"

resources/Documentation/Examples/ADayForFreshSushi.txt

@@ -5,6 +5,8 @@ Index: Person who comments on the player's every action
 Description: A complete story by Emily Short, called "A Day for Fresh Sushi", rewritten using Inform 7. Noteworthy is the snarky commenter who remarks on everything the player does, but only the first time each action is performed.
 For: Z-Machine
 
+^^{characters (people): reacting to the player's actions}
+
 The following is an almost-completely-faithful rewrite of Emily Short's _A Day for Fresh Sushi_, which was originally written using the (very different) Inform 6 programming language. The – let us be honest and call it a gimmick – of this game is the evil fish, who has some unpleasant remark to offer on pretty much every action. But the effect would wear off fast if he repeated himself, so these comments need to be single-use only.
 
 Inform 7's repeated action syntax makes it much tidier to write the same scenario, so:

resources/Documentation/Examples/AE.txt

@@ -5,6 +5,8 @@ Index: Region off-limits to a player without VIP pass
 Description: Using regions to block access to an entire area when the player does not carry a pass, regardless of which entrance they use.
 For: Z-Machine
 
+^^{Region off-limits to a player without VIP pass}
+
 Rules about going to regions make it easy to exclude the player from a large portion of the map, even if there are many connecting paths to the region. For instance, in this story it would be annoying to have to write a rule about all four exits by which the player could reach the film set area:
 
 	{*}"A&E"

resources/Documentation/Examples/AHaughtySpirit.txt

@@ -5,6 +5,8 @@ Index: Windows in high places
 Description: Windows overlooking lower spaces which will prevent the player from climbing through if the lower space is too far below.
 For: Z-Machine
 
+^^{Windows in high places}
+
 Suppose we have a game in which the player can climb through windows which overlook rooms below. We want them to be allowed to climb out windows to reach a room on the same level or at most one level lower than the one they're on; otherwise, they should get a refusal, saying that they would break their neck.
 
 To figure out the height distance between the start room and the destination room, we might have a repeat loop look at all the directions one has to follow along the "best route" path between the two rooms, and record any ups and downs; then subtract the number of "up" steps from the number of "down" steps, and report what remains.

resources/Documentation/Examples/AHumbleWaysideFlower.txt

@@ -5,6 +5,8 @@ Index: People introduced by relative
 Description: Relations track the relationships between one character and another. Whenever the player meets a relative of someone they already know, they receive a brief introduction.
 For: Z-Machine
 
+^^{characters (people): tracking their relationships}
+
 First we define the relationships we choose to acknowledge:
 
 	{*}"A Humble Wayside Flower"

resources/Documentation/Examples/APointForNeverSavingTheGame.txt

@@ -5,6 +5,8 @@ Index: A point for never saving the game
 Description: In some of the late 1970s cave-crawl adventure games, an elaborate scoring system might still leave the player perplexed as to why an apparently perfect play-through resulted in a score which was still one point short of the supposed maximum. Why only 349 out of 350? The answer varied, but sometimes the last point was earned by never saving the game - in other words by playing it right through with nothing to guard against mistakes (except perhaps ``UNDO`` for the last command), and in one long session.
 For: Untestable
 
+^^{saving the game: reward for never saving}
+
 Here is one way to score this point with Inform:
 
 	Check saving the game for the first time: decrement the score.

resources/Documentation/Examples/AViewOfGreenHills.txt

@@ -5,6 +5,8 @@ Index: LOOK [direction] command
 Description: A ``LOOK`` [direction] command which allows the player to see descriptions of the nearby landscape.
 For: Z-Machine
 
+^^{looking+action+: in a direction}
+
 Suppose a game in which the player is wandering an open landscape with long vistas, allowing them to ``LOOK`` in some direction, or even look at an adjacent location.
 
 	{*}"A View of Green Hills"

resources/Documentation/Examples/AboutInformsRegularExpressionSupport.txt

@@ -5,6 +5,8 @@ Index: About Inform's regular expression support
 Description: Some footnotes on Inform's regular expressions, and how they compare to those of other programming languages.
 For: Untestable
 
+^^{regular expressions}
+
 There is not really any unanimity about what regular expression language is. The unix tools sed and grep extend on Kleene's original grammar. Henry Spencer's regex library extended on this again, and was a foundation for Perl, but Perl once again went further. Philip Hazel's PCRE, despite the name Perl Compatible Regular Expressions, makes further extensions still, and so on.
 
 Inform's regular expressions are modelled on those of Perl, as the best de facto standard we have, but a few omissions have been inevitable. Inform's regex matcher must occupy source code less than one hundredth the size of PCRE, and it has very little memory. Inform aims to behave exactly like Perl except as follows:

resources/Documentation/Examples/AboutTheExamples.txt

@@ -5,6 +5,8 @@ Index: About the examples
 Description: An explanation of the examples in this documentation, and the asterisks attached to them. Click the heading of the example, or the example number, to reveal the text.
 For: Untestable
 
+^^{examples}
+
 This is the first of about 400 numbered examples. In a few cases, such as this one, they provide a little background information, but almost all demonstrate Inform source text. The techniques demonstrated tend to be included either because they are frequently asked for, or because they show how to achieve some interesting effect.
 
 The same examples are included in **both** of the books of documentation, but in a different order: in *Writing with Inform*, they appear near the techniques used to make them work; in *The Inform Recipe Book*, they are grouped by the effects they provide. For instance, an example called [Do Pass Go], about the throwing of a pair of dice, appears in the [Randomness] section of *Writing with Inform* and also in the [Dice and Playing Cards] section of *The Inform Recipe Book*. Clicking the italicised WI and RB buttons at the right-hand side of an example's heading switches between its position in each book.

resources/Documentation/Examples/AccessAllAreas.txt

@@ -5,6 +5,8 @@ Index: The Pointy Hat of Liminal Transgression
 Description: The Pointy Hat of Liminal Transgression allows its wearer to walk clean through closed doors.
 For: Z-Machine
 
+^^{The Pointy Hat of Liminal Transgression}
+
 If somebody tries to walk through a closed door, the `can't go through closed doors rule` usually stops them. This is a rule belonging to the `check going` rulebook. These names are fairly explanatory when written out, but hard to remember: fortunately we don't need to remember them, as the Index panel contains a full inventory of the check, carry out and report rules for every action, showing all of their names and the order in which they are checked. (We can also find out which rules are stopping an action by typing the testing command ``ACTIONS``.)
 
 Here we make the rule do nothing provided a condition holds:

resources/Documentation/Examples/Actaeon.txt

@@ -5,6 +5,8 @@ Index: FOLLOW command
 Description: A ``FOLLOW`` command allowing the player to pursue a person who has just left the room.
 For: Z-Machine
 
+^^{>FOLLOW}
+
 Suppose we want the player to be able to go after characters who are moving around the map. The trick, of course, is that once characters are gone they are no longer visible to `"follow [person]"`, so we need `"follow [any person]"` to find them.
 
 	{*}"Actaeon"

resources/Documentation/Examples/ActorsStudio.txt

@@ -5,6 +5,8 @@ Index: Video camera that records all actions
 Description: A video camera that records actions performed in its presence, and plays them back with time-stamps.
 For: Z-Machine
 
+^^{Video camera that records all actions}
+
 Here we construct a video camera to track and play back actions:
 
 	{*}"The Actor's Studio"

resources/Documentation/Examples/Aftershock.txt

@@ -5,6 +5,8 @@ Index: Radios and other devices active when switched on
 Description: Modifying the rules for examining a device so that all devices have some specific behaviour when switched on, which is described at various times.
 For: Z-Machine
 
+^^{Radios and other devices active when switched on}
+
 The built-in behaviour of Inform is to print a line after a device is examined, saying whether the item is on or off. This is often inappropriate, and we could simply turn off that behaviour in general by instructing Inform to ignore the `examine devices rule` (see the chapter on [Rulebooks]).
 
 Perhaps, though, we would like continue to have a short passage about the action of any switched on device; we'd just like a little more control over what it says from time to time. And in that case, we might change the rule to give a new activity control over that portion of the description:

resources/Documentation/Examples/AgeOfSteam.txt

@@ -5,6 +5,8 @@ Index: Scene which starts and finishes
 Description: The railway-station examples so far put together into a short game called "Age of Steam".
 For: Z-Machine
 
+^^{Scene which starts and finishes}
+
 The following source is very short and simple, yet it already feels surprisingly interesting in play, because something is going on which the player does not control but must observe. The single scene both starts and finishes.
 
 	{*}"Age of Steam"

resources/Documentation/Examples/Ahem.txt

@@ -5,6 +5,8 @@ Index: Phrase to repeat a rule
 Description: Writing a phrase, with several variant forms, whose function is to follow a rule several times.
 For: Z-Machine
 
+^^{Phrase to repeat a rule}
+
 As we see in the example here, it is possible to use slashed variations in more than one place in a phrase, and to offer a number of separate forms. The main rule of thumb to remember is that value inputs for the phrase should always be separated by some text; so
 
 	To do/follow (chosen rule - a rule) exactly/precisely/just/-- (N - a number) time/times:

resources/Documentation/Examples/AirConditioningIsStandard.txt

@@ -5,6 +5,8 @@ Index: Paragraphs of flexible descriptions
 Description: Uses `writing a paragraph about` to make person and object descriptions that vary considerably depending on what else is going on in the room, including some randomised NPC interactions with objects or with each other.
 For: Z-Machine
 
+^^{Paragraphs of flexible descriptions}
+
 	{*}"Air Conditioning is Standard"
 	
 	Section 1 - The Garage

resources/Documentation/Examples/Alias-G.txt

@@ -5,6 +5,8 @@ Index: Telephones with standard American-length phone numbers
 Description: A telephone with phone numbers of the standard American seven-digit length.
 For: Glulx
 
+^^{Telephones with standard American-length phone numbers}
+
 Seven-digit telephone numbers are too long for Inform to handle when compiling to the Z-Machine, but they will work under Glulx. To have this example succeed, make sure that you have selected the Glulx option in your settings menu.
 
 	{*}"Alias"

resources/Documentation/Examples/AlienInvasionPart23-G.txt

@@ -5,6 +5,8 @@ Index: Preferences file loaded on replaying
 Description: Keeping a preference file that could be loaded by any game in a series.
 For: Glulx
 
+^^{Preferences file loaded on replaying}
+
 Suppose that we have a series of games each of which allows the player to select a puzzle difficulty level. When the player plays a new game in the series, we want them to start out by default with the same difficulty level they faced earlier on, so we store this information in a small preferences file, as follows:
 
 	{*}"Alien Invasion Part 23"

resources/Documentation/Examples/AllRoadsLeadToMars.txt

@@ -5,6 +5,8 @@ Index: Rooms player is forced to visit in order
 Description: Layout where the player is allowed to wander any direction he likes, and the map will arrange itself in order so that he finds the correct next location.
 For: Z-Machine
 
+^^{connections between rooms: changing}
+
 Suppose we want to allow the player to wander freely in any direction, but ourselves maintain control over the order in which they encounter the rooms. This sort of effect emphasises the order of the story-telling over any kind of rigorous simulation of space; on multiple play-throughs, the player might not find all the same rooms in the same locations.
 
 	{*}"All Roads Lead to Mars"

resources/Documentation/Examples/AlpacaFarm.txt

@@ -5,6 +5,8 @@ Index: USE action which divines rational behaviour for a wide range of possible
 Description: A generic ``USE`` action which behaves sensibly with a range of different objects.
 For: Z-Machine
 
+^^{USE action which divines rational behaviour for a wide range of possible nouns}
+
 This example takes the ordering of grammar lines to its logical extreme, sorting the player's input into different categories depending on the kind and condition of the objects mentioned.
 
 	{*}"Alpaca Farm"

resources/Documentation/Examples/Alpha.txt

@@ -5,6 +5,8 @@ Index: Testing command
 Description: Creating a beta-testing command that matches any line starting with punctuation.
 For: Z-Machine
 
+^^{Testing command}
+
 Sometimes we want to let testers of a game insert their own comments during a transcript, without those comments wasting turns of the game or producing lengthy or inappropriate parser errors. Many testers have a habit of prefacing comments with a punctuation mark, so let's say that we'd like to catch any command that starts with any punctuation at all:
 
 	{*}"Alpha"

resources/Documentation/Examples/AmericaStandsTall.txt

@@ -5,6 +5,8 @@ Index: Feet and inches
 Description: Describing height in feet and inches.
 For: Z-Machine
 
+^^{Feet and inches}
+
 	{*}"America Stands Tall"
 	
 	The Oval Office is a room. Josh and Toby are men in the Oval. A height is a kind of value. 5 foot 11 specifies a height. A person has a height. Josh is 5 foot 8. Toby is 5 foot 10.

resources/Documentation/Examples/Anchorite.txt

@@ -5,6 +5,8 @@ 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}
+
 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:
 
 	{*}"Anchorite"

resources/Documentation/Examples/AnnoyotronJr.txt

@@ -5,6 +5,8 @@ Index: Child who asks if we're there yet
 Description: A child who after a certain period in the car starts asking annoying questions.
 For: Z-Machine
 
+^^{characters (people): acting spontaneously: asking questions} ^^{actions: spontaneous by other people}
+
 	{*}"Annoyotron Jr"
 	
 	The Minivan is a room. The Open Road is outside from the Minivan. Pete is a man in the Minivan. "Pete [if the player has been in the Minivan for 3 turns]is starting to look bored[otherwise]is playing with his travel activity book[end if]."

resources/Documentation/Examples/AntSensitiveSunglasses.txt

@@ -5,6 +5,8 @@ Index: Varying room description text
 Description: What are activities good for? Controlling output when we want the same action to be able to produce very flexible text depending on the state of the world -- in this case, making highly variable room description and object description text.
 For: Z-Machine
 
+^^{Varying room description text}
+
 Suppose we want to create an object – or maybe even a series of objects – that warp the player's perception of every room description and object around them.
 
 We've already seen some ways to create variations in text. For instance, we could make a room description with if substitutions in it, like so:

resources/Documentation/Examples/Anteaters.txt

@@ -5,6 +5,8 @@ Index: Device to remember and play back actions
 Description: The player carries a gizmo that is able to record actions performed by the player, then force them to repeat those actions when the gizmo is dropped. This includes storing actions that apply to topics, as in ``LOOK UP ANTEATER COLONIES IN THE GUIDE``.
 For: Z-Machine
 
+^^{Device to remember and play back actions}
+
 	{*}"Anteaters"
 	
 	A book is a kind of thing. Understand "book" as a book. A book has a table name called the contents.

resources/Documentation/Examples/Apples.txt

@@ -5,6 +5,8 @@ Index: Disambiguation question giving items more explicit names
 Description: Prompting the player on how to disambiguate otherwise similar objects.
 For: Z-Machine
 
+^^{Disambiguation question giving items more explicit names}
+
 Inform by default detects whether two objects can be disambiguated by any vocabulary available to the player. If so, it asks a question; if not, it picks one of the identical objects at random.
 
 Generally this produces good behaviour. Occasionally, though, two objects have some distinguishing characteristic that doesn't appear in the object name. For instance, suppose we've created a class of apples that can be told apart depending on whether they've been bitten or not:

resources/Documentation/Examples/AsTheCrowFliesToIffleyLock-G.txt

@@ -5,6 +5,8 @@ Index: Grid references
 Description: Calculated walking distances based on grid references at start and end of a walk.
 For: Glulx
 
+^^{Grid references}
+
 The Ordnance Survey National Grid reference system (OSGB) was developed in 1936 for the great retriangulation, which led to the building of many concrete pillars on British hilltops and to today's maps. The full range of values is enormous, since OSGB can specify any point in the British Isles to an accuracy of 1m. Fortunately, we only want to use positions in the town of Oxford, which sits fully inside a modest rectangular portion of square `SP`. So:
 
 	{*}"As The Crow Flies To Iffley Lock"

resources/Documentation/Examples/Aspect.txt

@@ -5,6 +5,8 @@ Index: Understanding units as part of the name of a thing
 Description: Understanding aspect ratios (a unit) in the names of televisions.
 For: Z-Machine
 
+^^{Understanding units as part of the name of a thing}
+
 Named properties are not the only kind that Inform is able to understand referring to an object. We can also use unit and number properties to distinguish things from one another, as here, where televisions have aspect ratios:
 
 	{*}"Aspect"

resources/Documentation/Examples/BadHairDay.txt

@@ -5,6 +5,8 @@ Index: Examining the player
 Description: Change the player's appearance in response to ``EXAMINE ME``.
 For: Z-Machine
 
+^^{examining+action+: the player}
+
 	{*}"Bad Hair Day"
 	
 	The Foyer is a room. "A mirror hangs over the table, tempting you to check your appearance before going in with all the others."

resources/Documentation/Examples/Baedeker.txt

@@ -5,6 +5,8 @@ Index: Producing an EPS floorplan
 Description: Creating a floorplan of the cathedral using the locations from previous examples.
 For: Z-Machine
 
+^^{Producing an EPS floorplan}
+
 If our map is largely or entirely set inside a single building, we might want to produce something that resembles a floorplan. It's possible to do this with a little tweaking, like so:
 
 	{*}"Baedeker"

resources/Documentation/Examples/Ballpark.txt

@@ -5,6 +5,8 @@ Index: Saying a number in round numbers
 Description: A new `to say` definition which allows the author to say `"[a number in round numbers]"` and get verbal descriptions like ``a couple of`` or ``a few`` as a result.
 For: Z-Machine
 
+^^{Saying a number in round numbers}
+
 Sometimes it is more sensible to describe numbers roughly than in exact terms. For instance, we might want to have our player perceive ``many people`` rather than ``forty-two people`` on entering a room. To achieve this, we might write our own `to say` phrase.
 
 	{*}"Ballpark"

resources/Documentation/Examples/BaritoneBass.txt

@@ -5,6 +5,8 @@ Index: Allowing the player to describe the main character before starting play
 Description: Letting the player pick a vocal range (or perhaps other characteristics) before starting play.
 For: Z-Machine
 
+^^{Allowing the player to describe the main character before starting play}
+
 The `reading a command` activity is rather advanced; for the moment, what we need to understand is that we're intervening in commands at the start of play and insisting that the player's first instruction to the game consist of a choice of vocal range. After that point, it will be set and play will proceed as normal.
 
 	{*}"Baritone, Bass"

resources/Documentation/Examples/BarterBarter.txt

@@ -5,6 +5,8 @@ Index: GIVE action for other characters
 Description: Allowing characters other than the player to give objects to one another, accounting for the possibility that some items may not be desired by the intended recipients.
 For: Z-Machine
 
+^^{giving it to+action+: for other characters}
+
 By default, if we make no modifications, telling one player to give something to another will fail, even if persuasion succeeds. This is because the default behaviour of the ``GIVE`` command is interrupted by the `block giving rule` – since in many cases we do not want people to exchange objects freely.
 
 However, suppose that we do want characters to be able to exchange articles freely: we allow persuasion to succeed and turn off the `block giving rule`.

resources/Documentation/Examples/BattleOfRidgefield.txt

@@ -5,6 +5,8 @@ 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
 
+^^{Death message replaced}
+
 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.
 
 This example relies on a standard extension to avoid any fancy programming:

resources/Documentation/Examples/BayLeavesAndHoneyWine.txt

@@ -5,6 +5,8 @@ Index: Producing an EPS map of Greece
 Description: Creating a map of Greece using the locations from previous examples.
 For: Z-Machine
 
+^^{Producing an EPS map of Greece}
+
 The map-maker can be used in quite versatile ways, in short; though the default is a schematic line-and-box affair, that is hardly the only option. While the EPS created is not always the result of our dreams, Inform usually can be made to do most of the hard and boring part, leaving the author to do only a bit of aesthetic touchup.
 
 In many previous examples, we have sent hapless deities wandering around a map of Greece; we might like to chart that for ourselves, in a semi-realistic fashion. So:

resources/Documentation/Examples/Beachfront.txt

@@ -5,6 +5,8 @@ Index: SEARCHing for an item which moves into play
 Description: An item that the player can't interact with until they have found it by searching the scenery.
 For: Z-Machine
 
+^^{SEARCHing for an item which moves into play}
+
 Suppose we have our player, a detective, searching for evidence; we don't want them to be able to use this evidence until they have performed the action that reveals it, but after that it should be visible in the room when they look.
 
 A simple way to do this is to start the object – an envelope, in this scenario – out of play, and only move it into the location when the player looks for it:

resources/Documentation/Examples/BeeChambers.txt

@@ -5,6 +5,8 @@ Index: Maze with randomised room links
 Description: A maze with directions between rooms randomised at the start of play.
 For: Z-Machine
 
+^^{mazes (implementing): with randomised room links}
+
 Mazes are a traditional element of interactive fiction, often consisting of apparently identical rooms with exits that do not work reciprocally and which cause confusion.
 
 The methods of mapping mazes are now fairly well understood and mazes themselves tend to be regarded as tiresome rather than enjoyable by a large portion of the playing audience. However, if we did want to ignore the common wisdom and create a maze, randomly generated at the start of play, here would be one way to go about it:

resources/Documentation/Examples/BeekeepersApprentice.txt

@@ -5,6 +5,8 @@ Index: Examining everything at once
 Description: Making the ``SEARCH`` command examine all the scenery in the current location.
 For: Z-Machine
 
+^^{examining+action+: everything at once}
+
 We have to create a suitable action and say what it does, and to repeat what we do through all the scenery items. That needs material from subsequent chapters, but is quite ordinary Inform all the same:
 
 	{*}"Beekeeper's Apprentice"

resources/Documentation/Examples/BeingPeter.txt

@@ -5,6 +5,8 @@ Index: Attitude rules
 Description: A set of rules determining the attitude a character will take when asked about certain topics.
 For: Z-Machine
 
+^^{Attitude rules}
+
 Let's say that we're implementing a particularly irrational and volatile character. Some of the time she remains composed; some of the time she reacts with unexpected vehemence for reasons only partly related to what was said.
 
 Moreover, her responses are divided between successful and failing outcomes, where success indicates that she's not too upset and failure means that she is distraught; we use this to determine how the rest of the room reacts.

resources/Documentation/Examples/BeingPrepared.txt

@@ -5,6 +5,8 @@ Index: Pocket added to every jacket
 Description: A kind for jackets, which always includes a container called a pocket.
 For: Z-Machine
 
+^^{Pocket added to every jacket}
+
 	{*}"Being Prepared"
 	
 	A jacket is a kind of thing. A jacket is always wearable.

resources/Documentation/Examples/Belfry.txt

@@ -5,6 +5,8 @@ Index: Characters and objects with titles and special articles
 Description: You can see a bat, a bell, some woodworm, William Snelson, the sexton's wife, a bellringer and your local vicar here.
 For: Z-Machine
 
+^^{characters (people): with titles and special articles} ^^{things+kind+: with special articles}
+
 	{*}"Belfry"
 	
 	The Belfry is a room. A bat is in the Belfry. The bell is in the Belfry. Some woodworm are in the Belfry. A man called William Snelson is in the Belfry. A woman called the sexton's wife is in the Belfry. A man called a bellringer is in the Belfry.

resources/Documentation/Examples/BeneathTheSurface.txt

@@ -5,6 +5,8 @@ Index: Hiding things under other things
 Description: An "underlying" relation which adds to the world model the idea of objects hidden under other objects.
 For: Z-Machine
 
+^^{Hiding things under other things}
+
 The standard world model provides for the idea of containers and supporters, but this is not the only way that objects can relate to one another in the real world. Here we try adding the idea of concealment beneath another object:
 
 	{*}"Beneath the Surface"

resources/Documentation/Examples/BeverageService.txt

@@ -5,6 +5,8 @@ Index: DRINKing a potion which then goes away
 Description: A potion that the player can drink.
 For: Z-Machine
 
+^^{drinking+action+: a potion which then goes away}
+
 Some kinds of game objects – food, for instance – can only sensibly be used once, and should then be destroyed. The ``EAT`` command already implements this, but suppose we also had a category of drinkable potions:
 
 	{*}"Beverage Service"

resources/Documentation/Examples/Bibliophilia.txt

@@ -5,6 +5,8 @@ Index: Bookshelf with numerous books
 Description: A bookshelf with a number of books, where the player's command to examine something will be interpreted as an attempt to look up titles if the bookshelf is present, but otherwise given the usual response.
 For: Z-Machine
 
+^^{books (implementing): bookshelf with numerous books}
+
 Suppose we want a bookshelf with a very large number of books on it. They aren't to be taken or carried around in the game, but they should be mentioned, and the player should be allowed to look them up by name. Furthermore, the player's attempts to examine something unrecognised should be understood as an attempt to look up a title – but only when the player is in the presence of the books. The rest of the time such requests should be rejected in the usual way.
 
 	{*}"Bibliophilia"

resources/Documentation/Examples/Bic.txt

@@ -5,6 +5,8 @@ Index: Checking for missed properties
 Description: Testing to make sure that all objects have been given descriptions.
 For: Z-Machine
 
+^^{Checking for missed properties}
+
 It may occasionally be useful to check whether all objects in our game have a given property. Here we have a `not for release` section that will run at the start of the game and alert us to any objects lacking description:
 
 	{*}"Bic"

resources/Documentation/Examples/BigSkyCountry.txt

@@ -5,6 +5,8 @@ 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}
+
 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.
 
 	{*}"Big Sky Country"

resources/Documentation/Examples/BikiniAtoll.txt

@@ -5,6 +5,8 @@ Index: Banner printing at appropriate times
 Description: Delaying the banner for later.
 For: Z-Machine
 
+^^{banner text}
+
 	{*}"Bikini Atoll" by Edward Teller
 	
 	The Hut and the Tropical Beach are rooms.

resources/Documentation/Examples/Blackout.txt

@@ -5,6 +5,8 @@ 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}
+
 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:
 
 	{*}"Blackout"

resources/Documentation/Examples/Blankness.txt

@@ -5,6 +5,8 @@ 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}
+
 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.
 
 We can tidy this up in the `starting the virtual machine` activity, by temporarily changing the status line content. We will not provide game-pausing code here, because that is easily done by extension; so:

resources/Documentation/Examples/Blink.txt

@@ -5,6 +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}
+
 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:
 
 	{*}"Blink"

resources/Documentation/Examples/Bogart.txt

@@ -5,6 +5,8 @@ Index: Clothing that layers
 Description: Clothing for the player that layers, so that items cannot be taken off in the wrong order, and the player's inventory lists only the clothing that is currently visible.
 For: Z-Machine
 
+^^{clothing: layering and regions of the body}
+
 We have two things to keep track of with our layering clothing: what currently is covering something else; and what *can* cover something else. This implementation goes for a fairly simple treatment, assuming that each item of clothing will completely conceal those beneath it, and that we are not implementing entire sets of shirts, jackets, etc. But it will do for a demonstration.
 
 	{*}"Bogart"

resources/Documentation/Examples/Bosch.txt

@@ -5,6 +5,8 @@ Index: FULL SCORE using a list of stored actions
 Description: Creating a list of actions that will earn the player points, and using this both to change the score and to give ``FULL SCORE`` reports.
 For: Z-Machine
 
+^^{scoring: >FULL SCORE: using a list of stored actions}
+
 We could, if we wanted, make a table of stored actions all of which represent things that will earn points for the player. For instance:
 
 	{*}"Bosch"

resources/Documentation/Examples/BostonCream.txt

@@ -5,6 +5,8 @@ Index: Person who pursues their own goals each turn
 Description: A fuller implementation of Ogg, giving him a motivation of his own and allowing him to react to the situation created by the player.
 For: Z-Machine
 
+^^{characters (people): acting spontaneously} ^^{actions: spontaneous by other people}
+
 	{*}"Boston Cream"
 	
 	Use scoring.

resources/Documentation/Examples/BowlerHatsAndBabyGeese.txt

@@ -5,6 +5,8 @@ Index: Scenes which restrict movement
 Description: Creating a category of scenes that restrict the player's behaviour.
 For: Z-Machine
 
+^^{Scenes which restrict movement}
+
 Scenes can have properties – a fact that is very useful when it comes to writing a series of scenes that all need to act alike in some respect.
 
 Suppose we have a plot that features a number of scripted scenes, where we need the player to stand still and wait while the events of the scene play out. One way to set this up is to create a property for such scenes – let's call them `restricted` – and then write a rule that keeps the player in place while the scene happens:

resources/Documentation/Examples/Bribery.txt

@@ -5,6 +5,8 @@ Index: GIVE command extended
 Description: A ``GIVE`` command that gets rid of Inform's default refusal message in favor of something a bit more sophisticated.
 For: Z-Machine
 
+^^{giving it to+action+}
+
 If we want to rewrite the functionality of a command that usually ends with a `block...` rule, we will have to begin by turning the blocking off.
 
 	{*}"Bribery"

resources/Documentation/Examples/Brown.txt

@@ -5,6 +5,8 @@ Index: Red sticky label
 Description: A red sticky label which can be attached to anything in the game, or removed again.
 For: Z-Machine
 
+^^{Red sticky label}
+
 	{*}"Brown"
 	
 	The Shipping Room is a room. The red sticky label is a thing carried by the player. The description of the red sticky label is "It reads: AIRMAIL[if the label is part of something (called the parent)]. It is stuck to [the parent][end if]."

resources/Documentation/Examples/BruneseausJourney.txt

@@ -5,6 +5,8 @@ Index: Lighting and relighting a candle
 Description: A candle which reacts to lighting and blowing actions differently depending on whether it has already been lit once.
 For: Z-Machine
 
+^^{Lighting and relighting a candle}
+
 > "Sire," said the Minister of the Interior to Napoleon, "yesterday I saw the most intrepid man in your Empire." - "What man is that?" said the Emperor brusquely, "and what has he done?" - "He wants to do something, Sire." - "What is it?" - "To visit the sewers of Paris."
 > 	
 > This man existed and his name was Bruneseau.

resources/Documentation/Examples/BumpingIntoWalls.txt

@@ -5,6 +5,8 @@ Index: GOing an invalid direction produces a list of valid exits
 Description: Offering the player a list of valid directions if they try to go in a direction that leads nowhere.
 For: Z-Machine
 
+^^{>GO: invalid direction produces a list of valid exits}
+
 	{*}"Bumping into Walls"
 
 First we add an instruction to determine which ways lead to other rooms.

resources/Documentation/Examples/CactusWillOutliveUsAll.txt

@@ -5,6 +5,8 @@ Index: Characters killed off by trigger actions
 Description: For every character besides the player, there is an action that will cause that character to wither right up and die.
 For: Z-Machine
 
+^^{characters (people): killed off by trigger actions}
+
 	{*}"Cactus Will Outlive Us All"
 	
 	Death Valley is a room. Luckless Luke and Dead-Eye Pete are men in the Valley. A cactus is in the Valley. Persuasion rule: persuasion succeeds.

resources/Documentation/Examples/CampBethel.txt

@@ -5,6 +5,8 @@ Index: People who do new things each time the player looks
 Description: Creating characters who change their behaviour from turn to turn, and a survey of other common uses for alternative texts.
 For: Z-Machine
 
+^^{characters (people): randomly named and described}
+
 	{*}"Camp Bethel"
 	
 	Camp Bethel Kitchen is a room.

resources/Documentation/Examples/Candy.txt

@@ -5,6 +5,8 @@ Index: Assigning attributes randomly at the start of play
 Description: One of several identical candies chosen at the start of play to be poisonous.
 For: Z-Machine
 
+^^{Assigning attributes randomly at the start of play}
+
 Suppose we want to give the player a bag of candies, of which a random one is poisonous. We can pick which one should be poisoned at the start of play, like this:
 
 	{*}"Candy"

resources/Documentation/Examples/CapitalCity.txt

@@ -5,6 +5,8 @@ Index: Capitalised status line
 Description: To arrange that the location information normally given on the left-hand side of the status line appears in block capitals.
 For: Z-Machine
 
+^^{Capitalised status line}
+
 Not much is needed for this. The only noteworthy point is that it doesn't work by changing the left hand status line to `"[the player's surroundings in upper case]"`: it cannot do this because "the player's surroundings" is not a value. Instead, `"[the player's surroundings]"` is a text substitution sometimes printing the name of a room, sometimes printing "Darkness", and so on. We must therefore load it into a text first, and then apply "...in upper case".
 
 	{*}"Capital City"

resources/Documentation/Examples/Carnivale.txt

@@ -5,6 +5,8 @@ Index: Scope for large objects visible far away
 Description: An alternative to backdrops when we want something to be visible from a distance but only touchable from one room.
 For: Z-Machine
 
+^^{Scope for large objects visible far away}
+
 Suppose we want to make an object that (unlike a backdrop) is definitely located in one room, but can be seen from far off. We want to allow the player to interact with it from a distance, but only using those actions that require visibility. Other actions should be denied:
 
 	{*}"Carnivale"

resources/Documentation/Examples/CasinoBanale.txt

@@ -5,6 +5,8 @@ Index: Narration which changes as the player learns new facts
 Description: Creating room descriptions and object descriptions that change as the player learns new facts and pieces things together.
 For: Z-Machine
 
+^^{Narration which changes as the player learns new facts}
+
 In a work of interactive fiction that involves many new discoveries, we might want to change the way we narrate room descriptions and describe objects as the player learns new information.
 
 One approach to this is to create a model of the facts we want the player to find out, and attach some narrative text to each. When a fact becomes relevant to the story, that narrative text is shown to the player. So:

resources/Documentation/Examples/Cavetroll.txt

@@ -5,6 +5,8 @@ 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
 
+^^{Modifying and re-parsing an entered 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``.
 
 While we can deal with some of these instances by expanding our range of actions, at some point it becomes impossible to account for all the possible prepositional phrases that the player might want to tack on. So what do we do if we want to handle those appended bits of text sensibly?

resources/Documentation/Examples/Celadon.txt

@@ -5,6 +5,8 @@ Index: DROP applies even to objects the player carries indirectly
 Description: Using the enclosure relation to let the player drop things which they only indirectly carry.
 For: Z-Machine
 
+^^{dropping+action+: even objects the player carries indirectly}
+
 By default, Inform only lets the player drop those things which they are carrying – that is, those directly in their possession. Things inside satchels or on portable trays have to be taken first.
 
 If we want to change this behaviour, we might add a dropping rule that distinguishes between carrying and mere enclosure (introduced back in "The location of something" in the chapter on [Things]):

resources/Documentation/Examples/Centered.txt

@@ -5,6 +5,8 @@ Index: Status line with centered text, the easy way
 Description: Replacing the two-part status line with one that centers only the room name at the top of the screen.
 For: Z-Machine
 
+^^{Status line with centered text, the easy way}
+
 If we want to lay out the status line in some other way than with left-hand and right-hand entries, it is possible to do this as well. Later we will learn about the `rule for constructing the status line`, but here is a basic effect using this rule and an Inform extension called Basic Screen Effects.
 
 	{*}"Centered"

resources/Documentation/Examples/ChanelVersion1-G.txt

@@ -5,6 +5,8 @@ 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}
+
 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:
 
 	{*}"Chanel Version 1"

resources/Documentation/Examples/ChangeOfBasis.txt

@@ -5,6 +5,8 @@ Index: Sleep and waking
 Description: Implementing sleeping and wakeful states.
 For: Z-Machine
 
+^^{Sleep and waking}
+
 Suppose we want to allow the player to go to sleep some of the time:
 
 	{*}"Change of Basis"

resources/Documentation/Examples/Channel1.txt

@@ -5,6 +5,8 @@ Index: Channel 1. Television that can be referred to by channel
 Description: Understanding channels (a number) in the names of televisions.
 For: Z-Machine
 
+^^{Channel 1. Television that can be referred to by channel}
+
 We might want to allow every television to be tuned to a channel (a number property) which the player could refer to, so that
 
 - ``WATCH CHANNEL 13``

resources/Documentation/Examples/Channel2.txt

@@ -5,6 +5,8 @@ Index: Channel 2. Television with more advanced parsing
 Description: Understanding channels (a number) in the names of televisions, with more sophisticated parsing of the change channel action.
 For: Z-Machine
 
+^^{Channel 2. Television with more advanced parsing}
+
 Our previous implementation of televisions ([Channel 1]) doesn't accept ``TUNE FIFTIES TELEVISION TO CHANNEL 4``; neither does it deal with player input like ``TUNE TO CHANNEL 4 ON FIFTIES TELEVISION``, nor ``TUNE TO CHANNEL 4`` where no television is specified.
 
 When we are designing commands which involve two elements (here, a television and a channel number), it's usually a good idea to allow the player to specify those elements in either order, as we saw demonstrated briefly in [New commands for old grammar].

resources/Documentation/Examples/Cheesemakers.txt

@@ -5,6 +5,8 @@ Index: TALK TO command used with scenes
 Description: Scenes used to control the way a character reacts to conversation and comments, using a ``TALK TO`` command.
 For: Z-Machine
 
+^^{TALK TO command used with scenes}
+
 As we have seen, there are a number of different ways of controlling conversation in interactive fiction, and the best choice of way will depend quite a lot on what kind of work we're writing.
 
 One common model is to replace Inform's default ``ASK`` and ``TELL`` commands with a ``TALK TO`` command. This gives the player less control than they would otherwise have: instead of asking a character about any topic under the sun, they're restricted to seeing (or not seeing) a single sequence of text that the author has written in advance. On the other hand, such a system is harder for the player to break (since they can never ask about a topic that the author hasn't implemented), and easier for the author to tie into plot developments. If we give ``TALK TO`` different output at each scene, we get conversation that is always tied to the current state of the plot.

resources/Documentation/Examples/ChronicHintingSyndrome.txt

@@ -5,6 +5,8 @@ Index: Hints leading the player through conversation
 Description: Using name-printing rules to keep track of whether the player knows about objects, and also to highlight things they might want to follow up.
 For: Z-Machine
 
+^^{hint systems: leading the player through conversation}
+
 Suppose we have a conversation system in which it is important to keep track of which subjects the player has heard mentioned. If we're careful to mark subjects in brackets, we can use the `printing the name of` activity to record which things have been mentioned so far:
 
 	{*}"Chronic Hinting Syndrome"

resources/Documentation/Examples/Cinco.txt

@@ -5,6 +5,8 @@ Index: Containers referred to by contents
 Description: A taco shell that can be referred to (when it contains things) in terms of its contents.
 For: Z-Machine
 
+^^{containers+kind+: referred to by contents}
+
 It's fairly common that we want to be able to refer to a container in terms of what it has in it: a bottle of wine, a salt shaker, a chicken sandwich. The player is free to remove the contents again, and the object will go back to using its usual name:
 
 	{*}"Cinco"

resources/Documentation/Examples/CircleOfMisery.txt

@@ -5,6 +5,8 @@ Index: Using lists as rings
 Description: Retrieving items from an airport luggage carousel is such fun, how can we resist simulating it, using a list as a ring buffer?
 For: Z-Machine
 
+^^{lists: variations on use of lists}
+
 The only point we need to be careful about is that the carousel is simulated twice over, in the following text: once in the built-in way that objects are inside other objects, so that the luggage items are objects contained in the carousel object; but then again by the `circle of misery` list, a ring buffer keeping track of what order things are in. We need to be careful that these two records do not fall out of synchrony: anything put into the carousel must be added to the list, anything taken out must be removed. (In fact we forbid things to be added, for simplicity's sake.)
 
 	{*}"Circle Of Misery"

resources/Documentation/Examples/ClaimsAdjustment.txt

@@ -5,6 +5,8 @@ Index: Photographs referred to by subject matter
 Description: An instant camera that spits out photographs of anything the player chooses to take a picture of.
 For: Z-Machine
 
+^^{Photographs referred to by subject matter}
+
 We start by creating a camera and a photograph object. As usual when we want to have a kind of object that can be dispensed in bulk, we start off with a bunch of identical instances of the object out of play (in this case, kept in an out-of-play container called `film roll`); we can then move them into play and give them characteristics when they're needed.
 
 Each photograph can depict exactly one thing – we're assuming that the player is not a landscape photographer here – so we create a relation to indicate what is shown by each photograph. We'll then use that relation to determine how photographs are described, named, and parsed:

resources/Documentation/Examples/CloakOfDarkness.txt

@@ -5,6 +5,8 @@ Index: Standard IF demonstration
 Description: Implementation of "Cloak of Darkness", a simple example game that for years has been used to demonstrate the features of IF languages.
 For: Z-Machine
 
+^^{Standard IF demonstration}
+
 _Cloak of Darkness_ is a brief example game that has been implemented in nearly every IF system currently used. It hasn't got much claim to complexity or richness, but it does exemplify many of the standard things one might want an IF language to be able to do: define descriptions and the results of actions, assign synonyms to nouns, create new verbs, handle darkness, track repeated acts, and so on.
 
 Here is what the game looks like in Inform:

resources/Documentation/Examples/Cloves.txt

@@ -5,6 +5,8 @@ Index: Adverbs used in commands
 Description: Accepting adverbs anywhere in a command, registering what the player typed but then cutting them out before interpreting the command.
 For: Z-Machine
 
+^^{adverbs used in commands}
+
 It has sometimes been suggested that IF should allow for the player to use adverbs, so that doing something ``CAREFULLY`` will have a different effect from doing it ``QUICKLY``. There are several inherent challenges here: it's a good idea to make very sure the player knows all their adverb options, and the list of possibilities should probably not be too long.
 
 Another trick is that adverbs complicate understanding commands, because they can occur anywhere: one might type ``GO WEST CAREFULLY`` or ``CAREFULLY GO WEST``, and ideally the game should understand both. After reading a command is the best point to do this sort of thing, because we can find adverbs, interpret them, and remove them from the command stream. So:

resources/Documentation/Examples/Clueless.txt

@@ -5,6 +5,8 @@ Index: Murderer chosen randomly at start of play
 Description: A murderer for the mystery is selected randomly at the beginning of the game.
 For: Z-Machine
 
+^^{Murderer chosen randomly at start of play}
+
 `When play begins` is the best point to initialise any aspects of the game that are meant to change between playings. For instance, in this scenario, we would randomly select one of the other characters to be guilty of murder:
 
 	{*}"Clueless"

resources/Documentation/Examples/ComplimentaryPeanuts.txt

@@ -5,6 +5,8 @@ Index: Conversation based on keyword recognition
 Description: A character who responds to keywords in the player's instructions and remarks, even if there are other words included.
 For: Z-Machine
 
+^^{dialogue: based on keyword recognition}
+
 The `reading a command` activity is not the only point at which we can interact with snippets, as it happens; it is merely the most useful. `The player's command` can be consulted at other points, however, as in this example of your somewhat deaf (or distracted, or simply cussed) Aunt:
 
 	{*}"Complimentary Peanuts"

resources/Documentation/Examples/ControlCenter.txt

@@ -5,6 +5,8 @@ Index: Describing objects with parts
 Description: Objects which automatically include a description of their component parts whenever they are examined.
 For: Z-Machine
 
+^^{descriptions (displayed): objects with parts}
+
 It is straightforward to make a rule that anything with parts must mention all those parts during an ``EXAMINE`` command:
 
 	{*}"Control Center"

resources/Documentation/Examples/CopperRiver.txt

@@ -5,6 +5,8 @@ Index: LOOK mentions only currently useful objects
 Description: Manipulating room descriptions so that only interesting items are mentioned, while objects that are present but not currently useful to the player are ignored.
 For: Z-Machine
 
+^^{looking+action+: mentioning only currently useful objects}
+
 In a very dense environment, we might want to offer the player room descriptions in which only the currently-interesting items are mentioned, while other objects are suppressed even if they are present. In effect, this takes the idea of scenery and makes it more flexible: different things might become background objects or foreground objects at different times during play.
 
 There are a wide range of possible reasons to do this – to shift the narrative emphasis, to change the mood of the game by highlighting different parts of the environment, to show the game from the perspective of different viewpoint characters – but in the following example, our goal is to show the player only the objects that are currently useful for puzzles.

resources/Documentation/Examples/CornerOfNoAndWhere.txt

@@ -5,6 +5,8 @@ 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}
+
 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.
 
 Note that this example _only_ works if the Settings for it are set to the Z-machine story file format: it does not work on the default Glulx setting, which has a different screen arrangement.

resources/Documentation/Examples/CostaRicanOrnithology.txt

@@ -5,6 +5,8 @@ Index: Book with various contents
 Description: A fully-implemented book, answering questions from a table of data, and responding to failed consultation with a custom message such as ``You flip through the Guide to Central American Birds, but find no reference to penguins.``
 For: Z-Machine
 
+^^{books (implementing): with various contents}
+
 The following relies on quite a number of features we haven't met yet: tables, rules for printing names, instructions for understanding the player's commands. It is offered simply as an example of how a fully implemented book might be handled in Inform.
 
 	{*}"Costa Rican Ornithology"

resources/Documentation/Examples/Croft.txt

@@ -5,6 +5,8 @@ Index: DROPPING into and onto things
 Description: Adding special reporting and handling for objects dropped when the player is on a supporter, and special entering rules for moving from one supporter to another.
 For: Z-Machine
 
+^^{dropping+action+: into and onto things}
+
 Suppose that we have a design in which the player spends lots of time on enterable supporters, and in which we want to report certain actions – dropping things onto those supporters, or leaping from one to another – in a new way. We might begin by adding some action variables to help us keep track of the situation:
 
 	{*}"Croft"

resources/Documentation/Examples/Crusoe.txt

@@ -5,6 +5,8 @@ Index: Printing the description of something activity
 Description: Adding a "printing the description of something" activity.
 For: Z-Machine
 
+^^{Printing the description of something activity}
+
 Suppose we want to add rules so that any time we examine a charred object (and most of our objects can be charred), a line about the charring is appended to the end of the object description. We could use `after examining...`, but perhaps we would prefer for the sentence about the charring not to appear in its own paragraph.
 
 This is an ideal occasion for a new activity. We look at the action index for `examining` to identify the rule that causes the old behaviour (in this case, the `standard examining rule`); replace this with a new rule that calls our activity; and write our `printing the description` activity in such a way that it uses an object's description without forcing a paragraph return afterward.

resources/Documentation/Examples/Curare.txt

@@ -5,6 +5,8 @@ Index: Cyclical randomisation of named objects
 Description: A phrase that chooses and names the least-recently selected item from the collection given, allowing the text to cycle semi-randomly through a group of objects.
 For: Z-Machine
 
+^^{Cyclical randomisation of named objects}
+
 	{*}"Curare"
 	
 	A thing has a number called the last use. The last use of a thing is usually 0.

resources/Documentation/Examples/DayOne.txt

@@ -5,6 +5,8 @@ Index: Scene which plays through a series of events in order, then ends
 Description: A scene which plays through a series of events in order, then ends when the list of events is exhausted.
 For: Z-Machine
 
+^^{Scene which plays through a series of events in order, then ends}
+
 	{*}"Day One"
 	
 	Lecture is a scene. Lecture begins when play begins.

resources/Documentation/Examples/DearthAndTheMaiden.txt

@@ -5,6 +5,8 @@ Index: Restrictions preventing inappropriate behaviour
 Description: Our heroine, fallen among gentleman highwaymen, is restrained by her own modesty and seemliness.
 For: Z-Machine
 
+^^{Restrictions preventing inappropriate behaviour}
+
 The following example, indebted to the late Georgette Heyer, is suggestive:
 
 	{*}"Dearth and the Maiden"

resources/Documentation/Examples/DelayedGratification.txt

@@ -5,6 +5,8 @@ Index: WAIT UNTIL [time] command
 Description: A ``WAIT UNTIL [time]`` command which advances until the game clock reaches the correct hour.
 For: Z-Machine
 
+^^{WAIT UNTIL [time] command}
+
 	{*}"Delayed Gratification"
 	
 	Hanging around until is an action applying to one time.

resources/Documentation/Examples/DeliciousDeliciousRocks.txt

@@ -5,6 +5,8 @@ Index: Sanity-check stage before the Before rules
 Description: Adding a sanity-check stage to decide whether an action makes any sense, which occurs before any before rules, implicit taking, or check rules.
 For: Z-Machine
 
+^^{Sanity-check stage before the Before rules}
+
 In some cases, we may want to add new stages to action processing. One possibility is a stage where we check the sanity of what the player is trying to do before executing any of the other commands; so that we avoid, for instance
 
 	> EAT ROCK

resources/Documentation/Examples/DemocraticProcess.txt

@@ -5,6 +5,8 @@ Index: PUT and INSERT automatically TAKE first
 Description: Making something happen automatically before an item is put into a box.
 For: Z-Machine
 
+^^{PUT and INSERT automatically TAKE first}
+
 `stop the action` is most useful when we need to write rules that will have to stop the action some of the time but at other times let it pass. For example, let's create a polling station, where the idea is to ``TAKE BALLOT``, ``VOTE``, and then ``PUT BALLOT IN MACHINE``:
 
 	{*}"Democratic Process"

resources/Documentation/Examples/Depth.txt

@@ -5,6 +5,8 @@ Index: Containers that calculate internal volume and available room
 Description: Receptacles that calculate internal volume and the amount of room available, and  cannot be overfilled.
 For: Z-Machine
 
+^^{containers+kind+: that calculate internal volume and available room}
+
 In the following, we pretend that every item has a cuboidal shape. Every thing has a length, width and depth, while a `measured container` also has interior dimensions. (Thus a 10x10x10 container with 1cm-thick sides might have interior dimensions 9x9x9.)
 
 	{*}"Depth"

resources/Documentation/Examples/Dimensions.txt

@@ -5,6 +5,8 @@ Index: Weighbridge
 Description: This example draws together the previous snippets into a working implementation of the weighbridge.
 For: Z-Machine
 
+^^{Weighbridge}
+
 The following is not a very sophisticated approach, because it does not allow for weight to accumulate: if we put a gold ingot into a paper bag, then put the bag on the balance platform, only the bag's weight will register. But it will do for a first try.
 
 	{*}"Dimensions"

resources/Documentation/Examples/DinnerIsServed.txt

@@ -5,6 +5,8 @@ Index: Window connecting two rooms
 Description: A window between two locations. When the window is open, the player can reach through into the other location; when it isn't, access is barred.
 For: Z-Machine
 
+^^{Window connecting two rooms}
+
 	{*}"Dinner is Served"
 	
 	Street in Kolonaki is a room. "There is a single round table out on the street here, and a window more or less at knee level looks down into the Olive Tree Gyro Shop, which is partly basement."

resources/Documentation/Examples/DisenchantmentBay1.txt

@@ -5,6 +5,8 @@ Index: The charter boat
 Description: A running example in this chapter, Disenchantment Bay, involves chartering a boat. This is the first step: creating the cabin.
 For: Z-Machine
 
+^^{The charter boat}
+
 To begin with the title:
 
 	{*}"Disenchantment Bay"

resources/Documentation/Examples/DisenchantmentBay10.txt

@@ -5,6 +5,8 @@ Index: Disenchantment Bay 10. Clothing and possessions
 Description: Disenchantment Bay: things for the player and the characters to wear and carry.
 For: Untestable
 
+^^{Disenchantment Bay 10. Clothing and possessions}
+
 At this point we can dress both the Captain and the player with some appropriate props:
 
 	{*}The captain wears a baseball cap. The description of the cap is "It says, THE WORST DAY FISHING IS BETTER THAN THE BEST DAY WORKING."