Adam, Your solution has the virtue of an extreme simpleness, but don’t define a safe dropping location, e.g. a rescue zone outside the perilous locations (aside the issue of the non-overlapping regions…)
Best regards from Italy,
dott. Piergiorgio.
OK, let’s take on a couple more.
Standard Rules: Actions 2
§10. Removing it from.
removing it from is a curiosity. I can’t say whether I’ve ever used the command or not. Perhaps I tried it once, as an experiment. This is something testers try in my games, which I appreciate, since it inevitably blows past my custom responses for taking.
Removing it from is an action applying to two things.
The removing it from action translates into Inter as "Remove".
The specification of the removing it from action is "Removing is not really
an action in its own right. Whereas there are many ways to put something down
(on the floor, on top of something, inside something else, giving it to
somebody else, and so on), Inform has only one way to take something: the
taking action. Removing exists only to provide some nicely worded replies
to impossible requests, and in all sensible cases is converted into taking.
Because of this, it's usually a bad idea to write rules about removing:
if you write a rule such as 'Instead of removing the key, ...' then it
won't apply if the player simply types TAKE KEY instead. The safe way to
do this is to write a rule about taking, which covers all possibilities."
The action is a bit of a pasteboard mask that either fails or else is transmogrified into something different, complicating a taking action via an added, indirect object.
As a first step, the noun needs to be held by something—a second noun. The first check verifies this relationship.
Check an actor removing something from (this is the can't remove what's not inside rule):
if the holder of the noun is not the second noun:
if the actor is the player:
say "But [regarding the noun][they] [aren't] there now." (A);
stop the action.
Next: a check to determine if the noun is immediately held by a person. This isn’t the iterative tree-walking check found in yesterday’s this is the can't take people's possessions rule. Despite appearances (and the implications of the rule’s name), possessions are handled more exhaustively later. The real news here is a redirect, in the case of removing something held by the player, to taking off.
This is accomplished via an as-yet unused phrase, convert to the [action name] on the noun. This isn’t found anywhere in the documentation. In fact, we’ll have to jump to very nearly the end of the Standard Rules to uncover its meaning.
§38. Action conversion is a trick used in the Standard Rules to simplify the implementation of actions: it allows one action to become another one mid-way, without causing spurious action failures. (There are better ways to make user-defined actions convert, and some of the examples show this.)
Users in this case are authors. What if we authors wish to avoid spurious action failures, too? In any case, this phrasing appears several times in the Standard Rules.
Check an actor removing something from (this is the can't remove from people rule):
let the owner be the holder of the noun;
if the owner is a person:
if the owner is the actor, convert to the taking off action on the noun;
if the actor is the player:
say "[regarding the noun][Those] [seem] to belong to [the owner]." (A);
stop the action.
An action still… active at this point now hits a wall. The second noun is dropped, and a taking action begins. In this way, more in-depth checks regarding possessions will occur as taking rules. No removing it from action lives, as-is, past the check phase of action processing.
Check an actor removing something from (this is the convert remove to take rule):
convert to the taking action on the noun.
Finally, and this might come as a surprise (I had never considered doing such a thing), the can't take component parts rule, a check against taking a part of something (I recently used a knife handle as an example) is listed at the very front of the rulebook.
The can't take component parts rule is listed before the can't remove what's not
inside rule in the check removing it from rules.
§12. Dropping.
I suspect that dropping, especially in this post carrying capacity world, sees far less traffic than taking does. In Repeat the Ending, it isn’t possible to drop things! The same is true for the Thief in my Zorkian work in progress. Thieves covet, after all, and while Zork I’s thief discarded rubbish everywhere, can’t rubbish be a question of taste?
Dropping is an action applying to one thing.
The dropping action translates into Inter as "Drop".
The specification of the dropping action is "Dropping is one of five actions
by which an actor can get rid of something carried: the others are inserting
(into a container), putting (onto a supporter), giving (to someone else) and
eating. Dropping means dropping onto the actor's current floor, which is
usually the floor of a room - but might be the inside of a box if the actor
is also inside that box, and so on.
The can't drop clothes being worn rule silently tries the taking off action
on any clothing being dropped: unlisting this rule removes both this behaviour
and also the requirement that clothes cannot simply be dropped."
§13. Check.
Dropping has fewer complexities, though one elaborate rule waits at the end of the check rulebook.
Players cannot drop themselves, but, since selves cannot be taken either, the rulebook starts with a bit of Nelsonian wit.
Check an actor dropping (this is the can't drop yourself rule):
if the noun is the actor:
if the actor is the player:
say "[We] [lack] the dexterity." (A);
stop the action.
Parts of the player cannot be dropped.
Check an actor dropping something which is part of the actor (this is the
can't drop body parts rule):
if the actor is the player:
say "[We] [can't drop] part of [ourselves]." (A);
stop the action.
The player cannot drop what they do not possess, though this isn’t checked by assessing the contents of the player. in the holder of the actor checks to see if the player and the noun are held by the same thing (room, shipping container, sound stage). A noun at one or more “layer” removed will get picked up in a subsequent rule.
ETA: I’ve stricken “sound stage” as an example, as this only applies to things that are in, not on the holder of the player.
Check an actor dropping (this is the can't drop what's already dropped rule):
if the noun is in the holder of the actor:
if the actor is the player:
say "[The noun] [are] already here." (A);
stop the action.
This next, more general rule will prevent the dropping of items that are not carried or worn but are otherwise in-scope. This includes items in carried containers, a thing some authors will probably want to remedy. I think the structure here is interesting. There are two affirmative offramps before the action-stopping message.
Check an actor dropping (this is the can't drop what's not held rule):
if the actor is carrying the noun, continue the action;
if the actor is wearing the noun, continue the action;
if the actor is the player:
say "[We] [haven't] got [regarding the noun][those]." (A);
stop the action.
Next, a convenience. Inform will attempt to remove worn clothing automatically if the player attempts to drop such items. If removal fails, the action stops without a message. This makes sense: only the author might know why a piece of clothing can’t be removed.
Check an actor dropping (this is the can't drop clothes being worn rule):
if the actor is wearing the noun:
if the actor is the player:
say "(first taking [the noun] off)[command clarification break]" (A);
silently try the actor trying taking off the noun;
if the actor is wearing the noun, stop the action;
And finally, a new level of carrying capacity management: dropping things while in/on containers/supporters with carrying capacity limits. This is a convenience for authors who wish to simulate such things. The default carrying capacity of anything providing that property is 100, so it would be very hard to an author to trigger such a limit by accident.
Rooms, fortunately, have no such limits (though compilers sometimes do).
Check an actor dropping (this is the can't drop if this exceeds carrying
capacity rule):
let the receptacle be the holder of the actor;
if the receptacle is a room, continue the action; oom floors have infinite capacity
if the receptacle provides the property carrying capacity:
if the receptacle is a supporter:
if the number of things on the receptacle is at least the carrying
capacity of the receptacle:
if the actor is the player:
now the prior named object is nothing;
say "[There] [are] no more room on [the receptacle]." (A);
stop the action;
otherwise if the receptacle is a container:
if the number of things in the receptacle is at least the carrying
capacity of the receptacle:
if the actor is the player:
now the prior named object is nothing;
say "[There] [are] no more room in [the receptacle]." (B);
stop the action;
§14. Carry out.
As will often be the case, execution is simpler than preparation.
Carry out an actor dropping (this is the standard dropping rule):
now the noun is in the holder of the actor.
§15. Report.
And that is all! Once again, the output is separate from the outcome, leaving us room to “get in front of it” with an after or first report rule if we wish.
That’s two more. The next post will be a tad longer, since putting it on and inserting it into are back to back, and both involve a fair amount of checking.
Let’s keep going. There are a lot of actions to get through!
Standard Rules: Actions 3
§16. Putting it on.
The action by which portable items are placed on supporters.
Putting it on is an action applying to two things.
The putting it on action translates into Inter as "PutOn".
The specification of the putting it on action is "By this action, an actor puts
something he is holding on top of a supporter: for instance, putting an apple
on a table."
putting it on is perhaps the most common means of applying the support relation. There are several checks that occur before the relation is set.
§17. Check
The rulebook begins with a conversion that considers down—a direction. This is a rarity that accounts for the idiomatic put [something] down. It also applies to cases where the actor attempts to put [something] on [the holder of the actor], ie, a player in a boxcar putting a widget in the boxcar.
Check an actor putting something on (this is the convert put to drop where possible rule):
if the second noun is down or the actor is on the second noun,
convert to the dropping action on the noun.
Next, a rule quite similar to the can't drop what's not held rule. There are two affirmative “offramps” before an implicit take attempt. If the take fails, the action stops there. Otherwise, the action continues.
Check an actor putting something on (this is the can't put what's not held rule):
if the actor is carrying the noun, continue the action;
if the actor is wearing the noun, continue the action;
carry out the implicitly taking activity with the noun;
if the actor is carrying the noun, continue the action;
stop the action.
The integrity of dimensional space is maintained by preventing a thing from being placed on top of itself. That’s an oversimplification, though. Inform goes much further, checking to verify that the common ancestor of component parts cores for noun and second noun are not the same.
component parts core is another I6 computation, with the idea that a handle and a coin slot might share as a component parts core a slot machine device. It’s defined much later in the Phrase Definitions section of the Standard Rules and goes unmentioned in the documentation.
Check an actor putting something on (this is the can't put something on itself rule):
let the noun-CPC be the component parts core of the noun;
let the second-CPC be the component parts core of the second noun;
let the transfer ceiling be the common ancestor of the noun-CPC with the second-CPC;
if the transfer ceiling is the noun-CPC:
if the actor is the player:
say "[We] [can't put] something on top of itself." (A);
stop the action.
Next, a straightforward check: an actor can only put things on supporters.
Check an actor putting something on (this is the can't put onto what's not a supporter rule):
if the second noun is not a supporter:
if the actor is the player:
say "Putting things on [the second noun] [would achieve] nothing." (A);
stop the action.
It isn’t possible to place worn items on supporters. The method for handling this is similar to the one used for dropping worn items.
Check an actor putting something on (this is the can't put clothes being worn rule):
if the actor is wearing the noun:
if the actor is the player:
say "(first taking [regarding the noun][them] off)[command clarification break]" (A);
silently try the actor trying taking off the noun;
if the actor is wearing the noun, stop the action.
Finally, another carrying capacity check.
Check an actor putting something on (this is the can't put if this exceeds
carrying capacity rule):
if the second noun provides the property carrying capacity:
if the number of things on the second noun is at least the carrying capacity
of the second noun:
if the actor is the player:
say "[There] [are] no more room on [the second noun]." (A);
stop the action.
§18. Carry out.
What does it mean to be supported by something? In Inform, it is expressed as a relation. A very short carry out phase.
Carry out an actor putting something on (this is the standard putting rule):
now the noun is on the second noun.
§19. Report.
This one is a little more complex than the report rules we’ve seen so far. That’s because Inform handles output for cases involving one noun differently than it does situations with multiple objects. For multiple objects, we see for the first time this curious phrase: the I6 parser is running multiple actions. This is defined much later in the Standard Rules via I6. Instead of sentence-long responses for placing multiple objects, we are treated to a rather succinct “Done.”.
Report an actor putting something on (this is the concise report putting rule):
if the action is not silent:
if the actor is the player and the I6 parser is running multiple actions:
say "Done." (A);
stop the action;
continue the action.
A player placing one thing at a time is handled strictly at the natural language layer.
Report an actor putting something on (this is the standard report putting rule):
if the action is not silent:
say "[The actor] [put] [the noun] on [the second noun]." (A).
§20. Inserting it into.
I’ve always seen inserting it into and putting it on as close cousins. Both are used to orient things spacially within the environment in terms of common kinds of thing types, containers and supporters. We are working with the former, now.
Inserting it into is an action applying to two things.
The inserting it into action translates into Inter as "Insert".
The specification of the inserting it into action is "By this action, an actor puts
something he is holding into a container: for instance, putting a coin into a
collection box."
§21. Check.
The checks are similar to those involving supporters, with a couple of important additions specific to containers.
We once again start with a sweeping conversion to the dropping action. Interestingly, even though insert [something] down is not idiomatic, it is covered here.
Check an actor inserting something into (this is the convert insert to drop where
possible rule):
if the second noun is down or the actor is in the second noun,
convert to the dropping action on the noun.
This is situated where it is to prevent an actor from implicitly taking a thing from a container before placing it once more where it was found.
Check an actor inserting something into (this is the can't insert what's already inserted rule):
if the noun is in the second noun:
if the actor is the player:
say "[The noun] [are] already there." (A);
stop the action.
This rule, like it’s related putting it on check, prevents things from being placed inside of themselves. It also evaluates the action in terms of component parts core and common ancestry.
Check an actor inserting something into (this is the can't insert something into itself rule):
let the noun-CPC be the component parts core of the noun;
let the second-CPC be the component parts core of the second noun;
let the transfer ceiling be the common ancestor of the noun-CPC with the second-CPC;
if the transfer ceiling is the noun-CPC:
if the actor is the player:
say "[We] [can't put] something inside itself." (A);
stop the action.
This will also look quite familiar: implicit taking for nouns that aren’t carried. Note that worn items aren’t grated a free pass; they are handled explicitly later on in the rulebook.
Check an actor inserting something into (this is the can't insert what's not held rule):
if the actor is carrying the noun, continue the action;
if the actor is wearing the noun, continue the action;
carry out the implicitly taking activity with the noun;
if the actor is carrying the noun, continue the action;
stop the action.
A rule that is relevant to insertion but not placement: checking to determine if the container is closed.
Check an actor inserting something into (this is the can't insert into closed containers rule):
if the second noun is a closed container:
if the actor is the player:
say "[The second noun] [are] closed." (A);
stop the action.
Just because a specific check against “closed container” might succeeds, we aren’t yet certain that we are dealing with a container at all.
Check an actor inserting something into (this is the can't insert into what's not a
container rule):
if the second noun is not a container:
if the actor is the player:
say "[regarding the second noun][Those] [can't contain] things." (A);
stop the action.
A clothing-specific evaluation. The Standard Rules will attempt to remove clothing automatically and, should the items remain worn, the action will fail.
Check an actor inserting something into (this is the can't insert clothes being worn rule):
if the actor is wearing the noun:
if the actor is the player:
say "(first taking [regarding the noun][them] off)[command clarification break]" (A);
silently try the actor trying taking off the noun;
if the actor is wearing the noun, stop the action;
As a final check, an evaluation of carrying capacity. These checks will seldom fail unless the author has made arrangements for that.
Check an actor inserting something into (this is the can't insert if this exceeds
carrying capacity rule):
if the second noun provides the property carrying capacity:
if the number of things in the second noun is at least the carrying capacity
of the second noun:
if the actor is the player:
now the prior named object is nothing;
say "[There] [are] no more room in [the second noun]." (A);
stop the action.
§22. Carry out.
All is accomplished with a relation. As a side comment, I was very surprised to realize that space in Inform is almost entirely codified by relations. Surprised, really, because I think you can do a lot of game authorship without ever really thinking about them.
Carry out an actor inserting something into (this is the standard inserting rule):
now the noun is in the second noun.
§23. Report.
A very similar playbook here. Concise responses for multiple objects, and a single sentence for a single noun.
Report an actor inserting something into (this is the concise report inserting rule):
if the action is not silent:
if the actor is the player and the I6 parser is running multiple actions:
say "Done." (A);
stop the action;
continue the action.
Report an actor inserting something into (this is the standard report inserting rule):
if the action is not silent:
say "[The actor] [put] [the noun] into [the second noun]." (A).
Next up: eating, which ought to be fun, and going, which might involve some heavy lifting.
Notably, this checks if the noun is in the holder—this rule will not fire for supporters! If you try to drop something twice while standing on a supporter, you’ll get a different message than when in a room or container.
I think you listed the same rule twice here?
Thanks for this. I missed that distinction.
Yep! Should’ve been the can't put clothes being worn rule.
This seems like a (very minor) bug. I thought maybe there was an alternate grammar where it would make sense, but no – you can INSERT X INTO Y, DROP X IN Y, or PUT X IN Y, with a few choices of preposition; but there’s no grammar that lacks a preposition. There is a grammar for PUT X DOWN, but this maps to dropping, not inserting it into. Actually, this means the down case will never trigger with idiomatic input even for putting it on – it’s completely redundant in both rules. Maybe a relic of older logic.
There will be times when I can include more than two actions in a post, as some of these actions are minimally implemented. My current goal is to post at least two a day, though I won’t be hard on myself if I don’t manage. The Standard Rules supports a wealth of built-in options, and we’ll never cover them all without a bit of commitment.
Standard Rules: Actions 3
§24. Eating.
There isn’t a lot to the eating action, but it’s been a constant feature since pre-commercial days. I appreciate the observation that, out of the box, eating and eating alone among the standard actions can banish a noun to nowhere.
Eating is an action applying to one thing.
The eating action translates into Inter as "Eat".
The specification of the eating action is "Eating is the only one of the
built-in actions which can, in effect, destroy something: the carry out
rule removes what's being eaten from play, and nothing in the Standard
Rules can then get at it again.
Note that, uncontroversially, one can only eat things with the 'edible'
either/or property. Until 2011, the action also required that the foodstuff
had to be carried by the eater, which meant that a player standing next
to a bush with berries who typed EAT BERRIES would force a '(first taking
the berries)' action. This is no longer true. Taking is now only forced if
the foodstuff is portable."
§25. Check.
As a first check, the eating action will evaluate the noun for the edible property (edibility is declared possible in the “Physical World Model” portion of the Standard Rules). Attempting to eat something inedible will result in failure.
Check an actor eating (this is the can't eat unless edible rule):
if the noun is not a thing or the noun is not edible:
if the actor is the player:
say "[regarding the noun][They're] plainly inedible." (A);
stop the action.
Even if this must be an unusual case, I appreciate the exhaustive nature of this next evaluation: edible clothing must be taken off before the Standard Rules will make an eating attempt.
Check an actor eating (this is the can't eat clothing without removing it first rule):
if the actor is wearing the noun:
if the actor is the player:
say "(first taking [the noun] off)[command clarification break]" (A);
try the actor trying taking off the noun;
if the actor is wearing the noun, stop the action.
The Standard Rules’s method for determining the owner of the noun will be familiar, as it uses the same while loop for checking ownership while taking.
Check an actor eating (this is the can't eat other people's food rule):
if the actor does not hold the noun and the noun is enclosed by a person:
let the owner be the holder of the noun;
while the owner is not a person:
now the owner is the holder of the owner;
if the owner is not the actor:
if the actor is the player and the action is not silent:
say "[The owner] [might not appreciate] that." (A);
stop the action;
A final check for any action that has survived thus far: a thing must be held to be eaten. This will prevent, for instance, players from eating things held by closed, transparent containers.
Check an actor eating (this is the can't eat portable food without carrying it rule):
if the noun is portable and the actor is not carrying the noun:
carry out the implicitly taking activity with the noun;
if the actor is not carrying the noun, stop the action.
§26. Carry out.
Next stop: oblivion!
Carry out an actor eating (this is the standard eating rule):
now the noun is nowhere.
§27. Report.
A brief epilogue.
Report an actor eating (this is the standard report eating rule):
if the action is not silent:
if the actor is the player:
say "[We] [eat] [the noun]. Not bad." (A);
otherwise:
say "[The actor] [eat] [the noun]." (B).
Time to buckle up.
§28. Going.
I’ll break this code into chunks, as there is a lot to work through.
Section 3 - Standard actions which move the actor
Going is an action applying to one visible thing.
The going action translates into Inter as "Go".
The specification of the going action is "This is the action which allows people
to move from one room to another, using whatever map connections and doors are
to hand. The Standard Rules are written so that the noun can be either a
direction or a door in the location of the actor: while the player's commands
only lead to going actions with directions as nouns, going actions can also
happen as a result of entering actions, and then the noun can indeed be
a door."
going is the first built-in action we’ve examined that makes use of action variables. action variables aren’t frequently discussed, despite being a core element of Inform’s action processing framework. In this, they remind me a bit of relations. If my search technique is correct, the term “action variables” has appeared just 151 times here at intfiction.
The ones used in the implementation of going are fortunately legible. It isn’t hard to tell what they might be for.
The going action has a room called the room gone from (matched as "from").
The going action has an object called the room gone to (matched as "to").
The going action has an object called the door gone through (matched as "through").
The going action has an object called the vehicle gone by (matched as "by").
The going action has an object called the thing gone with (matched as "with").
The setting action variables rulebook is declared in the Variables and Rulebooks section of the Standard Rules, but it is, I believe, empty in its default state. This is the first rule for setting action variables that we have encountered.
For readers who, like me, don’t use action variables often, it’s useful to note where they are set. The setting action variables rulebook is called by the generate action rule before it initates standard action processing. That is, after parsing the command but before any action begins. In this way, authors can guarantee that certain variables are assigned prior to the before stage of action processing.
Anecdotally, I think a lot of parser players like to type as few characters as possible. I believe I might have typed go through [door] once, and only as a test.
ETA: “going through” a door is actually an entering action that converts to going [door], so while the question of doors-as-nouns is of general interest, typing go through [door] has only indirect application here.
Rule for setting action variables for going (this is the standard set going variables rule):
now the thing gone with is the item-pushed-between-rooms;
now the room gone from is the location of the actor;
if the actor is in an enterable vehicle (called the carriage),
now the vehicle gone by is the carriage;
let the target be nothing;
if the noun is a direction:
let direction D be the noun;
let the target be the room-or-door direction D from the room gone from;
otherwise:
if the noun is a door, let the target be the noun;
if the target is a door:
now the door gone through is the target;
now the target is the other side of the target from the room gone from;
now the room gone to is the target.
§29. Check.
Many of these rules are kindnesses that insulate the player from tedium such as specifically typing, for instance, get off ladder before attempting to go somewhere.
Check an actor going when the actor is on a supporter (called the chaise)
(this is the stand up before going rule):
if the actor is the player:
say "(first getting off [the chaise])[command clarification break]" (A);
silently try the actor exiting.
I have no experience with implementing vehicles, but the general flow of things ought to make intuitive sense since we have been thinking a great deal players being held by continers and supporters.
Check an actor going (this is the can't travel in what's not a vehicle rule):
let nonvehicle be the holder of the actor;
if nonvehicle is the room gone from, continue the action;
if nonvehicle is the vehicle gone by, continue the action;
if the actor is the player:
if nonvehicle is a supporter:
say "[We] [would have] to get off [the nonvehicle] first." (A);
otherwise:
say "[We] [would have] to get out of [the nonvehicle] first." (B);
stop the action.
This one seems like the big reveal in a long thread about doors working incorrectly. Still, doors cannot be moved or removed from play, so authors wishing to blink them in and out of existence will have to bend things a bit. This machinery will prevent the automatic opening of undescribed doors, a feature handled by a subsequent rule.
Check an actor going (this is the can't go through undescribed doors rule):
if the door gone through is not nothing and the door gone through is undescribed:
if the actor is the player:
say "[We] [can't go] that way." (A);
stop the action.
The standard rules will attempt the opening of closed doors while going. If opening fails, the failure message will be the last word.
Check an actor going (this is the can't go through closed doors rule):
if the door gone through is not nothing and the door gone through is closed:
if the actor is the player:
say "(first opening [the door gone through])[command clarification break]" (A);
silently try the actor opening the door gone through;
if the door gone through is open, continue the action;
stop the action.
This next rule includes our first sighted use of a direction as a noun in the Standard Rules. We’ll recognize the phrasing the room-or-door [direction] from the documentation. Its purpose is to update the room gone to action variable whether it is on the other side of a door or simply just a room direction from the room gone from.
Check an actor going (this is the determine map connection rule):
let the target be nothing;
if the noun is a direction:
let direction D be the noun;
let the target be the room-or-door direction D from the room gone from;
otherwise:
if the noun is a door, let the target be the noun;
if the target is a door:
now the target is the other side of the target from the room gone from;
now the room gone to is the target.
A final check printing one of the most familiar rejections in parser IF: “You can’t go that way.” If the room gone to is nothing, the action ends in failure. Note the perhaps rarely seen special case for handling a door leading nowhere.
Check an actor going (this is the can't go that way rule):
if the room gone to is nothing:
if the door gone through is nothing:
if the actor is the player:
say "[We] [can't go] that way." (A);
stop the action;
if the actor is the player:
say "[We] [can't], since [the door gone through] [lead] nowhere." (B);
stop the action.
§30. Carry out.
The carry out phase for going is more complex than that of other actions we’ve seen so far. Most of this is derived from the possibility of vehicle involvement.
surreptitiously is never mentioned in the documentation. However, it is codified in Phrase Definitions later on. I’ll pull the brief description of its use from there.
§39. The “surreptitiously” phrases shouldn’t be used except in the Standard Rules because they temporarily violate invariants for the object tree and the light variables; the SR uses them carefully in situations where it’s known to work out all right.
The rulebook checks light soon hereafter, though I am not certain what sorts of problems with the object-tree might be headed off in this way. In any case, if the action gets this far, the player and, if applicable, their vehicle, are moved to the room gone to during going.
Clarification:
Carry out an actor going (this is the move player and vehicle rule):
if the vehicle gone by is nothing,
surreptitiously move the actor to the room gone to during going;
otherwise
surreptitiously move the vehicle gone by to the room gone to during going;
if the location is not the location of the player:
now the location is the location of the player.
Any action processing rule might move a backdrop, but backdrop locations are only updated here, when the player goes somewhere. Authors wishing to update backdrops manually will need to use the magic phrase update backdrop positions.
Carry out an actor going (this is the move floating objects rule):
if the actor is the player or the player is within the vehicle gone by
or the player is within the thing gone with:
update backdrop positions.
I cannot say what this phrase does. Is it a variation on basic visibility rule? Inform needs to check light in a room gone to, certainly. If someone has a definitive answer, I’ll add it here.
Update:
Carry out an actor going (this is the check light in new location rule):
if the actor is the player or the player is within the vehicle gone by
or the player is within the thing gone with:
surreptitiously reckon darkness.
That isn’t all. The report an actor going rule is the most elaborate action processing rule we’ve seen yet. Most of it, though, applies to atypical cases.
§31. Report.
In the simplest and most likely cases, the Standard Rules will produce a room description with going spacing conventions. This is another I6 invocation that we author’s aren’t meant to use ourselves. Here is the relevant passage from “Phrase Definitions”:
§35. This is a unique quasi-action, using the secondary action processing stage only. A convenience, but also an anomaly, and let’s not encourage its further use.
Does secondary action processing stage mean specific action processing? Without knowing more, I would not personally encourage its further use.
Report an actor going (this is the describe room gone into rule):
if the player is the actor:
if the action is not silent:
produce a room description with going spacing conventions;
Next, an exhaustive accounting for many possible outcomes involving NPCs. There isn’t a lot to say, editorially speaking, other than to note the combinatorial explosion arising from scenarios involving vehicles, npcs, and multiple directions.
Simple cases involving an NPC going, beginning from the player’s location:
otherwise:
if the noun is a direction:
if the location is the room gone from or the player is within the
vehicle gone by or the player is within the thing gone with:
if the room gone from is the room gone to:
continue the action;
otherwise:
if the noun is up:
say "[The actor] [go] up" (A);
otherwise if the noun is down:
say "[The actor] [go] down" (B);
otherwise:
say "[The actor] [go] [noun]" (C);
Cases in which an NPC goes to the player’s location from another room:
let the back way be the opposite of the noun;
if the location is the room gone to:
let the room back the other way be the room back way from the
location;
let the room normally this way be the room noun from the
room gone from;
if the room back the other way is the room gone from or
the room back the other way is the room normally this way:
if the back way is up:
say "[The actor] [arrive] from above" (D);
otherwise if the back way is down:
say "[The actor] [arrive] from below" (E);
otherwise:
say "[The actor] [arrive] from [the back way]" (F);
otherwise:
say "[The actor] [arrive]" (G);
A case in which the player witnesses an NPC going to a room that is not the location:
otherwise:
if the back way is up:
say "[The actor] [arrive] at [the room gone to] from above" (H);
otherwise if the back way is down:
say "[The actor] [arrive] at [the room gone to] from below" (I);
otherwise:
say "[The actor] [arrive] at [the room gone to] from [the back way]" (J);
If the noun is not a direction, ie, is a door.
otherwise if the location is the room gone from:
say "[The actor] [go] through [the noun]" (K);
otherwise:
say "[The actor] [arrive] from [the noun]" (L);
Next, texts to be appended to an NPC’s going message if they are riding a vehicle.
if the vehicle gone by is not nothing:
say " ";
if the vehicle gone by is a supporter:
say "on [the vehicle gone by]" (M);
otherwise:
say "in [the vehicle gone by]" (N);
Similar treatment for things an NPC might push between rooms.
if the thing gone with is not nothing:
if the player is within the thing gone with:
say ", pushing [the thing gone with] in front, and [us] along too" (O);
otherwise if the player is within the vehicle gone by:
say ", pushing [the thing gone with] in front" (P);
otherwise if the location is the room gone from:
say ", pushing [the thing gone with] away" (Q);
otherwise:
say ", pushing [the thing gone with] in" (R);
If the player is riding along. Note the addition of a bog-standard looking action (as opposed to produce a room description with going spacing conventions).
if the player is within the vehicle gone by and the player is not
within the thing gone with:
say ", taking [us] along" (S);
say ".";
try looking;
continue the action;
For any output missing a period, this last touch is afforded.
say ".";
And so it goes! That’s two more. Next time: entering and exiting. looking is not too far off in the distance, which I’ve felt a bit of dread over. As always, comments, corrections, and questions are welcome.
Are you misunderstanding the purpose of match as? That doesn’t control the parser – it controls the compiler. It means you can write rules like the following:
[ matches the room gone from ]
Before going to the Lab:
[ matches the room gone to ]
After going from the Dark Room:
[ matches the door gone through ]
Instead of going through the Suspicious Portal:
[ matches the vehicle gone by ]
Before going by the Cute Pink Convertible:
It has no influence on whether or not you can command GO THROUGH – that would be controlled by an Understand rule. (I think it is defined in the Standard Rules and maps to the entering action.)
I like to add additional action variables to core actions. For example:
The taking action has an object called the prior locale.
Rule for setting action variables for taking:
now the prior locale is the holder of the noun.
And now you can write rules like:
Instead of taking the detonator stick from the grenade when the location is indoors:
say "You'd just blow yourself up too."
Huh? That’s odd. The setting action variables rule already set the room gone to. Doesn’t that mean this rule is completely redundant? It doesn’t even stop the action, so simply removing it from the rulebook would probably have no effect whatsoever in the vast majority of cases. (It could make a difference if Before or Instead rules modify the map connections, I guess. Maybe that’s the real reason it exists.)
Not just vehicle movement but also pushing things between rooms. Strangely though, I see there’s no mention of the thing gone with in the first carry out rule, though it’s covered in the other two… is that a bug, or is there some detail I’m missing? (It wouldn’t be right for the vehicle gone by and the thing gone with to hold the same object – consider getting in a tractor and using it to push a bale of hay to the next room.)
This maps to the I6 routine SilentlyConsiderLight(). (Sounds like the exact opposite, doesn’t it?) This does an OffersLight() check on the player’s location (might be a chair, vehicle, etc). If false, it sets the location global to the thedark pseudo-room. real_location remains set to the player’s actual location.
Yeah, I see what you mean. go through/-- [door] enters, but it converts to a going [door] action in the end. It doesn’t look like go [door] can directly initiate a going action, so door-as-noun only happens indirectly.
It could just be a last panic check before “You can’t go that way” fires.
It appears that the Standard Rules does not produce special output when a player pushes something between rooms. I’m not sure if the expectation is that the author will handle this themselves. It seems like something SR would acknowledge.
This
lab is a room. "Wow, what a lab!".
closet is east of lab.
block is in lab.
block is pushable between rooms.
produces
>push block east
closet
>
I’ve never done anything with pushing things between rooms, but it seems a little undercooked. Pushing converts to special going-with-push action, but that’s probably not as exotic as it sounds.
ETA
This is a good, succinct example. I think the photographing example in the documentation can come across as a bit overwhelming. This is much easier to process.
Note that action variables are for the author’s benefit, not the player’s! They’re what allow “instead of going through a locked door by car” or “instead of going north from the foyer with the trolley”. (Like Celtic said.)
In the case of going, this is also specially supported by the compiler, but you can add action variables to whatever actions you want—Counterfeit Monkey uses an action variable to allow “instead of waving the letter-remover creating a person”. It’s an advanced feature of Inform that Dialog lacks and I sometimes feel that absence quite keenly.
This, notably, is never supposed to happen—earlier parts of the Standard Rules said that only the player is expected to ever be undescribed.
There are a few things that happen when the player is moved normally that are skipped when the player is moved surreptitiously:
- “The location” is updated—this is actually a global variable for efficiency reasons, rather than being computed from “the location of the player”
- Backdrops and doors are moved to their proper positions
- Light is recalculated to see if it’s suddenly become dark or suddenly become light around the player
In this case, later parts of the going action handle these things, so it works out okay in the end. “During going” on surreptitious movement means that “the location” should be updated, but the other two still skipped. (That “during going” is on the “move surreptitiously” phrase, not on “the room gone to”.)
This bit made me curious about how the room description ends up being printed in the case where the player is within the thing gone with (e.g. the player is on a chair and an NPC is pushing the chair). Turns out that the room description heading ends up being printed twice, including once claiming that the player is inside the NPC - this is a known bug in 10.1.2.
I think I actually recall running into that bug and working around it.
I’m a bit perplexed about the carry out of eating: many foodstuff leaves leftovers, (e.g. apples and steak) which can even be useful (e.g. giving the steak bone to a guard dog, for an example based on the classical “distract the guard” puzzle), and I guess that providing a foodstuff/leftover swap mechanism isn’t a bad idea, at least IMVHO.
Best regards from Italy,
dott. Piergiorgio.
Sure, but that’s something an author would have to implement—the library tries to provide the simplest workable version.
Let’s keep moving.
Standard Rules: Actions 4
§32. Entering.
entering is not the same thing as going inside, though they might seem interchangeable at a distance. I imagine as the prototypical enterable thing a phone booth (with apologies to younger readers).
Entering is an action applying to one thing.
The entering action translates into Inter as "Enter".
The specification of the entering action is "Whereas the going action allows
people to move from one location to another in the model world, the entering
action is for movement inside a location: for instance, climbing into a cage
or sitting on a couch. (Entering is not allowed to change location, so any
attempt to enter a door is converted into a going action.) What makes
entering trickier than it looks is that the player may try to enter an
object which is itself inside, or part of, something else, which might in
turn be... and so on. To preserve realism, the implicitly pass through other
barriers rule automatically generates entering and exiting actions needed
to pass between anything which might be in the way: for instance, in a
room with two open cages, an actor in cage A who tries entering cage B first
has to perform an exiting action."
This is the first time we’ve encountered a rule for supplying a missing noun, isn’t it? Can this make trouble in a room with multiple enterable things? Perhaps streamlining behavior in the most common case (one enterable thing) makes this a good approach. I’ve spent so much time on getting Inform to decide or not decide on nouns over the years! I’m not sure that I can say.
Rule for supplying a missing noun while entering (this is the find what to enter
rule):
if something enterable (called the box) is in the location,
now the noun is the box;
otherwise continue the activity.
The find what to enter rule is listed last in the for supplying a missing noun
rulebook.
§33. Check.
The check entering rulebook is substantial.
Picking up where we left off last time: entering a door will convert to going noun.
Check an actor entering (this is the convert enter door into go rule):
if the noun is a door, convert to the going action on the noun.
I don’t know that I ever realized this! entering a direction converts to going noun.
Check an actor entering (this is the convert enter compass direction into go rule):
if the noun is a direction, convert to the going action on the noun.
Using the common ancestor for its criterion, the Standard Rules will prevent players from entering something that it is already inside.
Check an actor entering (this is the can't enter what's already entered rule):
if the actor is the noun, make no decision;
let the local ceiling be the common ancestor of the actor with the noun;
if the local ceiling is the noun:
if the player is the actor:
if the noun is a supporter:
say "But [we]['re] already on [the noun]." (A);
otherwise:
say "But [we]['re] already in [the noun]." (B);
stop the action.
The player can only enter enterable things. Output varies depending on whether or not specific words are used in the command. We have not encountered this technique so far. I would usually be wary of this kind of thing, but because this rule is working with a fixed number of possible commands, it seems fine.
Check an actor entering (this is the can't enter what's not enterable rule):
if the noun is not enterable:
if the player is the actor:
if the player's command includes "stand":
say "[regarding the noun][They're] not something [we] [can] stand on." (A);
otherwise if the player's command includes "sit":
say "[regarding the noun][They're] not something [we] [can] sit down on." (B);
otherwise if the player's command includes "lie":
say "[regarding the noun][They're] not something [we] [can] lie down on." (C);
otherwise:
say "[regarding the noun][They're] not something [we] [can] enter." (D);
stop the action.
Closed containers cannot be entered. No implicit open is attempted, which might be for the best. Who knows what’s in there?
Check an actor entering (this is the can't enter closed containers rule):
if the noun is a closed container:
if the player is the actor:
say "[We] [can't get] into the closed [noun]." (A);
stop the action.
A carrying capacity rule, with separate branches for handling containers and supporters separately.
Check an actor entering (this is the can't enter if this exceeds carrying
capacity rule):
if the noun provides the property carrying capacity:
if the noun is a supporter:
if the number of things on the noun is at least the carrying
capacity of the noun:
if the actor is the player:
now the prior named object is nothing;
say "[There] [are] no more room on [the noun]." (A);
stop the action;
otherwise if the noun is a container:
if the number of things in the noun is at least the carrying
capacity of the noun:
if the actor is the player:
now the prior named object is nothing;
say "[There] [are] no more room in [the noun]." (B);
stop the action;
Once again testing against the common ancestor, the standard rules will prevent players from entering something held (or held by something held, or held by something held by something held) by the player.
Check an actor entering (this is the can't enter something carried rule):
let the local ceiling be the common ancestor of the actor with the noun;
if the local ceiling is the actor:
if the player is the actor:
say "[We] [can] only get into something free-standing." (A);
stop the action.
The last and most complex rule is the implicitly pass through other barriers rule, which automates the entrances and exits via two loops. The first loop has the actor silently trying exiting until they either fail to exit or reach a common ancestor with the noun.
If applicable, the rule will then have the actor attempt entering, via a loop, the holder (or holder of the holder, and so forth) of the noun. This sounds tricky, and I think these loops generally are to my untrained eye, but an example might do a better job of explaining.
lab is a room. "Wow, what a booth!".
booth1 get. booth1 is an enterable container. it is scenery.
booth2 is in booth1. booth2 is an enterable container. it is scenery.
booth3 is in booth2. booth3 is an enterable container. it is scenery.
booth4 is in booth3. booth4 is an enterable container. it is scenery.
bootha is in lab. bootha is an enterable container. it is scenery.
boothb is in bootha. boothb is an enterable container. it is scenery.
boothc is in boothb. boothc is an enterable container. it is scenery.
boothd is in boothc. boothd is an enterable container. it is scenery.
yields
>enter booth4
(getting into booth1)
(getting into booth2)
(getting into booth3)
You get into booth4.>enter boothd
(getting out of booth4)
(getting out of booth3)
(getting out of booth2)
(getting out of booth1)
(getting into bootha)
(getting into boothb)
(getting into boothc)
You get into boothd.
Check an actor entering (this is the implicitly pass through other barriers rule):
if the holder of the actor is the holder of the noun, continue the action;
let the local ceiling be the common ancestor of the actor with the noun;
while the holder of the actor is not the local ceiling:
let the current home be the holder of the actor;
if the player is the actor:
if the current home is a supporter or the current home is an animal:
say "(getting off [the current home])[command clarification break]" (A);
otherwise:
say "(getting out of [the current home])[command clarification break]" (B);
silently try the actor trying exiting;
if the holder of the actor is the current home, stop the action;
if the holder of the actor is the noun, stop the action;
if the holder of the actor is the holder of the noun, continue the action;
let the target be the holder of the noun;
if the noun is part of the target, let the target be the holder of the target;
while the target is a thing:
if the holder of the target is the local ceiling:
if the player is the actor:
if the target is a supporter:
say "(getting onto [the target])[command clarification break]" (C);
otherwise if the target is a container:
say "(getting into [the target])[command clarification break]" (D);
otherwise:
say "(entering [the target])[command clarification break]" (E);
silently try the actor trying entering the target;
if the holder of the actor is not the target, stop the action;
convert to the entering action on the noun;
continue the action;
let the target be the holder of the target;
§34. Carry out.
Not much to see here, though I think the use of move to rather than setting a relation is interesting. Or is it? Then again, move to calls Inform 6 code. I can see that entering one of our above booths triggers the investigate player's awareness rule. The machinery associated with going is far more substantial, so this surreptitious move to might be even more… surreptitious.
If anyone has any insight into moving to room versus moving to enterable thing, I’d love to hear about it!
Carry out an actor entering (this is the standard entering rule):
surreptitiously move the actor to the noun.
§35. Report.
A brief report phase, complicated by the need to account for supporters and containers separately.
Report an actor entering (this is the standard report entering rule):
if the actor is the player:
if the action is not silent:
if the noun is a supporter:
say "[We] [get] onto [the noun]." (A);
otherwise:
say "[We] [get] into [the noun]." (B);
otherwise if the noun is a container:
say "[The actor] [get] into [the noun]." (C);
otherwise:
say "[The actor] [get] onto [the noun]." (D);
continue the action.
This is an interesting touch though: the locale description prints. This is the first time we’ve seen this trigger. It prints just the locale description and not a room description. If there is nothing to describe, then nothing prints.
Report an actor entering (this is the describe contents entered into rule):
if the actor is the player, describe locale for the noun.
§36. Exiting.
It is easier to exit than it is to enter, or at least there are at least fewer rules involved.
I observe that exiting only applies to containers. This interests me, since entering handled both while providing different output based on the noun’s kind. Inform converts exiting supporter actions to getting off.
Note also the declaration of an action variable, container exited from, as well as the absence of a rule for supplying a missing noun. It will be a while before we look at command grammar, but the exiting action does not support nouns. There are no nouns to miss! Exiting is understood as a request to get out of the player’s immediate holder.
Exiting is an action applying to nothing.
The exiting action translates into Inter as "Exit".
The exiting action has an object called the container exited from (matched as "from").
The specification of the exiting action is "Whereas the going action allows
people to move from one location to another in the model world, and the
entering action is for movement deeper inside the objects in a location,
the exiting action is for movement back out towards the main floor area.
Climbing out of a cupboard, for instance, is an exiting action. Exiting
when already in the main floor area of a room with a map connection to
the outside is converted to a going action. Finally, note that whereas
entering works for either containers or supporters, exiting is purely for
getting oneself out of containers: if the actor is on top of a supporter
instead, an exiting action is converted to the getting off action."
Setting action variables for exiting (this is the standard set exiting variables rule):
now the container exited from is the holder of the actor.
§37. Check.
There aren’t many rules to work through, here.
At the top of the rulebook, if the player attempts exiting while it is held by the location and there is a room outside of the location, the action will convert to going.
Check an actor exiting (this is the convert exit into go out rule):
let the local room be the location of the actor;
if the container exited from is the local room:
if the room-or-door outside from the local room is not nothing,
convert to the going action on the outside;
If the player attempts exiting while held by the location when there is no out outlet, the action will fail.
Check an actor exiting (this is the can't exit when not inside anything rule):
let the local room be the location of the actor;
if the container exited from is the local room:
if the player is the actor:
say "But [we] [aren't] in anything at the f story tense is present
tense]moment[otherwise]time[end if]." (A);
stop the action.
The standard rules will not attempt to open closed containers while exiting, which is consistent with rules governing entering.
Check an actor exiting (this is the can't exit closed containers rule):
if the actor is in a closed container (called the cage):
if the player is the actor:
say "You can't get out of the closed [cage]." (A);
stop the action.
The last check converts exiting when the player is on a supporter to the getting off action.
Check an actor exiting (this is the convert exit into get off rule):
if the actor is on a supporter (called the platform),
convert to the getting off action on the platform.
§38. Carry out.
This not-counting-parts holder incorporation must be meant to handle scenarios like Ferris wheels with their many carriages.
Carry out an actor exiting (this is the standard exiting rule):
let the former exterior be the not-counting-parts holder of the container exited from;
surreptitiously move the actor to the former exterior.
§39. Report.
I’m surprised to see output for exiting supporters, but, unlike the check rule converting exiting to getting off, this rule tests the container exited from rather than whether or not the player is on a supporter. Is this just a last-minute re-check to make sure the action variable hasn’t changed? Or is there some way this could happen organically?
Report an actor exiting (this is the standard report exiting rule):
if the action is not silent:
if the actor is the player:
if the container exited from is a supporter:
say "[We] [get] off [the container exited from]." (A);
otherwise:
say "[We] [get] out of [the container exited from]." (B);
otherwise:
say "[The actor] [get] out of [the container exited from]." (C);
continue the action.
Just as the Standard Rule does with entering, a light check is performed. Unlike entering a container, exiting produces a room description.
Report an actor exiting (this is the describe room emerged into rule):
if the actor is the player:
surreptitiously reckon darkness;
produce a room description with going spacing conventions.
One last nibble: the lightly-implemented getting off action, which has a small scope. Several check exiting rules will apply to it, which makes the check getting off rulebook significantly less complex.
Getting off is an action applying to one thing.
The getting off action translates into Inter as "GetOff".
The specification of the getting off action is "The getting off action is for
actors who are currently on top of a supporter: perhaps standing on a platform,
but maybe only sitting on a chair or even lying down in bed. Unlike the similar
exiting action, getting off takes a noun: the platform, chair, bed or what
have you."
§41. Check.
Only one check here, but some exiting checks may have occurred on our way here. There are two onramps, accounting for cases in which the actor is either on or carried by the noun. Otherwise, the action fails.
Check an actor getting off (this is the can't get off things rule):
if the actor is on the noun, continue the action;
if the actor is carried by the noun, continue the action;
if the actor is the player:
say "But [we] [aren't] on [the noun] at the f story tense is present
tense]moment[otherwise]time[end if]." (A);
stop the action.
§42. Carry out.
Just as was the case with exiting, getting off moves the actor to the not counting parts holder of the noun.
Carry out an actor getting off (this is the standard getting off rule):
let the former exterior be the not-counting-parts holder of the noun;
surreptitiously move the actor to the former exterior.
§43. Report.
That’s just about that, isn’t it?
Report an actor getting off (this is the standard report getting off rule):
if the action is not silent:
say "[The actor] [get] off [the noun]." (A);
continue the action.
Once again, a room description.
Report an actor getting off (this is the describe room stood up into rule):
if the actor is the player,
produce a room description with going spacing conventions.
That’s it for today. Next time, we must confront looking. I haven’t read too far ahead, but I feel this might be one of the more difficult ones. We’ll soldier through.
Hopefully!
I think it would just pick one arbitrarily. It’s not really a problem because, if it chooses the wrong one, you can just specify the correct one in the next command and you’re fine.
I was imagining cases where perhaps there was a timer running, or if there were some other consideration at work.
supplying a missing noun preempts a does the player mean rule, doesn’t it? Not that it would be a huge deal.
No, they’re completely unrelated – supplying a missing noun is used when there is no noun at all for an action that requires one (and even then, only if the grammar line does not have a noun), but does the player mean is used when the player named a noun but it was ambiguous.
Sorry, what I mean is that the author cannot implement a does the player mean rule for entering (edit: with no noun information specificed, multiple matched nouns like “box” for “tall box” and “short box” would be evauated), because supplying a missing noun will always handle the choice.
DTPM will try to fill in blanks when things aren’t equal, ie
lab is a room. "Wow, what a booth!".
closet is east of lab.
red is an enterable container in lab.
blue is an enterable container in lab.
green is an enterable container in lab.
purple is an enterable container in lab.
yellow is an enterable container in lab.
black is an enterable container in lab.
white is an enterable container in lab.
does the player mean doing something with black:
it is likely;
can produce
>touch
(black)
You feel nothing unexpected.>enter
You get into red.
I suppose, this project being as simple as it is, that “red” has been chosen by the supplying a missing noun rule based on source code order, but “black” has been chosen according to DTPM.
This isn’t some big gotcha, just something that might be unexpected.