I was fooling around some more, trying out 6E59 by going through the documentation and writing some sample code as I move along in an effort to determine what syntax has changed. I’m trying to write code at the level of the material found only up to the point where I’m at in the documentation (currently chapter 6), but it’s hard to limit things that way and I’m not really succeeding on that point. In any case I found myself (unwittingly) making an example that seems relevant to the discussion we’ve been having here about replacing procedural rules. Perhaps the example may also be generally useful to anyone browsing through the various posts of the forum.
The general idea of the test project is that the player-character has been abducted by <aliens, a baleful government agency, the girl scouts, whatever> and wakes up in a strange complex where, it would seem, his intelligence and reasoning skills are being tested by a serious of (very) simple puzzles that must be solved before moving further into the complex (and presumably toward an eventual door with an “exit” sign above it).
The example puzzle discussed here involved several cases where I may formerly have used a procedural rule, but now declined to do so since I’ve got the “Use no deprecated features” option active. The example involves a hallway with a door at one end; a mathematical notation is written on the door. At the other end of the hallway is a room with a numeric keypad. The player must enter the solution to the (very simple) equation into the keypad to remotely open the door. Sorry for the rough edges (deviating from the provided “test stuff” will quickly break things) and disorganized presentation of code, but after all it’s only an example in a test project (intended for my own use) rather than something from a polished game:
[code]Chapter 8 - Dark Hallway
There is a room called the Hallway Junction. [Description omitted as too confusing to post here]
There is a room called the Eastern Lab.
The door04 is a door. The door04 is north of the Hallway Junction and south of the Eastern Lab. The description of the door04 is “A doorway set in the wall at the northern end of the corridor. The door itself [if closed ]appears to be [otherwise]is[end if] a mechanical sliding hatch that retracts sideways into the wall when open. [unless open]Something is written on the surface of the door in dark red letters[otherwise]The door is currently open.[end if].” The door04 is privately-named. The printed name of the door04 is “sliding door”. Understand “door” or “sliding door” or “hatch” as the door04. The door04 is locked and not lockable. The door04 is scenery.
Some password01 are scenery in the Hallway Junction. The password01 are privately-named. The printed name of the password01 is “red numbers”. Understand “numbers” or “red numbers” or “writing” or “painted numbers” as the password01. The description of the password01 is “Written or painted on the door in large characters with some sort of dark red ink or dye is the following:[paragraph break]62 + 43[command clarification break]”.
Understand the command “read” as something new.
Reading is an action applying to one thing. Understand “read [something]” as reading.
Instead of reading the door04:
if the door04 is closed:
try examining the password01;
otherwise:
say “The door has retracted into the wall.”.
Instead of reading the password01:
try examining the password01.
Chapter 9 - Keypad Room
A room called the Device Room is south of the Hallway Junction. [The Device Room is a dark room.] The description of the Device Room is “A dark, square-shaped room, about twenty feet wide. The walls are made from a dense white material the with the consistency of very thick, hard rubber that nonetheless reflects light as though it were polished metal. A small device of some sort is built into the eastern wall about three feet off the floor.”
A keypad01 is in the Device Room. The keypad01 is scenery. The keypad01 is privately-named. The printed name of the keypad01 is “key pad”. Understand “small device” or “device” or “keypad” or “key pad” as the keypad01. The description of the keypad01 is “A numeric keypad, made of the same odd white material found throughout the area, is built into the eastern wall of this room. The keypad consists of eleven buttons as well as a small display of some sort set over the keys. This display currently reads: [kp01text of the keypad01].” The keypad01 has some indexed text called the kp01text.
[I’ll come back to fix that display for cases when the text string is empty at a later point in writing, likely using a simple say statement]
Report examining the keypad01 for the first time:
say “All but one of the buttons of the keypad are labelled with a numeral; the remaining button is labelled with the word ‘Send.’ The buttons are laid out in the following configuration:[paragraph break][fixed letter spacing]1 2 3[line break]4 5 6[line break]7 8 9[line break]0 Send[variable letter spacing][paragraph break]”
Instead of reading the keypad01:
try examining the noun.
An alphanumkey is a kind of thing. An alphanumkey has some text called the aklabel. The aklabel of an alphanumkey is usually “”. The description of an alphanumkey is usually “A button on a numeric keypad. This key is labelled: [aklabel of the item described].” Understand “key” or “button” as an alphanumkey.
Instead of reading an alphanumkey:
try examining the noun.
An alphanumkey called a one key is part of the keypad01. The aklabel of the one key is “1”.
An alphanumkey called a two key is part of the keypad01. The aklabel of the two key is “2”.
An alphanumkey called a three key is part of the keypad01. The aklabel of the three key is “3”.
An alphanumkey called a four key is part of the keypad01. The aklabel of the four key is “4”.
An alphanumkey called a five key is part of the keypad01. The aklabel of the five key is “5”.
An alphanumkey called a six key is part of the keypad01. The aklabel of the six key is “6”.
An alphanumkey called a seven key is part of the keypad01. The aklabel of the seven key is “7”.
An alphanumkey called an eight key is part of the keypad01. The aklabel of the eight key is “8”.
An alphanumkey called a nine key is part of the keypad01. The aklabel of the nine key is “9”.
An alphanumkey called a zero key is part of the keypad01. The aklabel of the zero key is “0”.
An alphanumkey called a send key is part of the keypad01. The aklabel of the send key is “Send”.
Carry out pushing the send key:
if kp01text of the keypad01 exactly matches the text “105”:
now the door04 is open;
now the door04 is not openable;
remove the password01 from play;
otherwise:
now the kp01text of the keypad01 is “”.
Report pushing the send key:
if the kp01text of the keypad01 exactly matches the text “105”:
say “You press the ‘Send’ key. Off to the north, you briefly hear a soft metallic clank.” instead.
[It was particularly hard to discern the syntax necessary for the next rule, since the “change x to y” formulation has been deprecated and “now” seems to be very sensitive when working with texts]
Carry out pushing an alphanumkey which is incorporated by the keypad01:
unless the noun is the send key:
let mendru be indexed text;
let mendru be “[kp01text of the keypad01][aklabel of the noun]”;
now the kp01text of the keypad01 is mendru.
Report pushing an alphanumkey which is incorporated by the keypad01:
unless the noun is the send key:
say “You press [the noun], causing a ‘[the aklabel of the noun]’ to appear on the small display above the keypad.” instead.
Inputting it into is an action applying to one topic and one thing. Understand “input [text] on [something]” as inputting it into. Understand “input [text] into [something]” as inputting it into. Understand “type [text] on [something]” as inputting it into. Understand “type [text] into [something]” as inputting it into. Understand “enter [text] on [something]” as inputting it into. Understand “enter [text] into [something]” as inputting it into.
A thing can be input-compatible. A thing is usually not input-compatible. The keypad01 is input-compatible.
Check inputting it into:
unless the second noun is input-compatible:
say “That doesn’t make sense in this context.” instead.
Check inputting into the keypad01:
let keycheck be indexed text;
let keycheck be “[the topic understood]”;
unless keycheck exactly matches the regular expression “send”, case insensitively:
if keycheck matches the regular expression “\D”:
say “Apart from the ‘Send’ button, only the numbers 1-9 and 0 are available on the keypad,” instead;
otherwise:
try pushing the send key instead.
[It was particularly hard to discern the syntax necessary for the next rule, since the “change x to y” formulation has been deprecated and “now” seems to be very sensitive when working with texts]
Carry out inputting into the keypad01:
let weldru be indexed text;
let weldru be “[kp01text of the keypad01][the topic understood]”;
now the kp01text of the keypad01 is weldru.
Report inputting into the keypad01:
say “You enter [the topic understood] using the keypad. The display above the buttons now reads: [the kp01text of the keypad01].”
Test stuff with “x door / read door / s / press one button / type 05 on keypad / press send key”.[/code]
The things that stood out in regard to the discussion here were:
a) In the past, I might have made exceptions to the Standard “report an actor pushing” rule for the keypad buttons; however tacking on an “instead” to the end of each unique report pushing rule was easy enough and seemed to take care of things in this case;
b) In the past, I would have designed the custom “inputting” action with a blocking check rule, such as
Check inputting it into (this is the general block useless inputting rule):
say “That doesn’t make any sense in this context.” instead.
and then made individual exceptions for kinds or things to which I wanted the inputting action to apply. I briefly considered applying emshort’s “activities” approach discussed earlier in the thread, but decided it wouldn’t be a true test of efficiency as “inputting” is only relevant for one device at this point. Writing one line giving the keypad an “input-compatible” property that all other things (at this point) lack and considering this property in the general blocking rule seemed to be an effective solution in this case.
A minor related point is that while it may seem like an aesthetically attractive idea not to go on a wild property-creating spree, something I learned while trying to work around some bugs in 5Z71 is that there’s no practical reason to be stingy with either/or properties. I had (by the standards of an average IF comp game) a shockingly large project where every single item (of which there were several thousand in existence due to heavy use of automatic generation) in the game world literally had scores of (mostly unused and inapplicable) either/or properties. I never saw any sort of performance degradation whatsoever related to such an approach (and I usually work on an old computer less powerful than a top-of-the-line cellphone). Thus using an either/or property as a foundation for simple blocking rules would seem to be yet another way to avoid using procedural exceptions.