An every turn event, but only when successful?

Suppose you have something like:

Every turn when monster is chasing, say "He's coming!"

Out-of-game actions don’t trigger this as they aren’t considered turns, nor do parser errors like trying to kiss something not animate. But checking inventory does, as well as other actions that have no real “result”. How do you specify whether an action should result in a turn or not?

I’m thinking specifically in cases like:

Instead of cutting apple with something dull, say "Not sharp enough."

I wouldn’t want that to take a turn because the player didn’t really do anything; they were preempted by the game from taking any real action. How do you treat this like a parser error or an impossibility, so that it doesn’t take a turn? Does this have to be done with a Check rule instead of an Instead? How does Inform decide when a turn occurs? Is it only when an in-game action succeeds?

Also, how do I prevent taking inventory from counting as a turn? I want to treat it as a report that refreshed your memory, not an “action” that would actually require time to go by, which is seemingly how Inform views a turn.

Someone pointed me toward the concept of making an action “timeless”, such as:

[code]Examining something is acting fast.
Looking is acting fast.

The take visual actions out of world rule is listed before the every turn stage rule in the turn sequence rules.

This is the take visual actions out of world rule: if acting fast, rule succeeds.[/code]

I’m not entirely sure how this is working. Is it simply that the rule is listed before the every turn stage rule, and the “if acting fast, rule succeeds” part is designed to be called 100% of the time on timeless actions, so the action gets referred to the rule placed before the ‘every turn stage rule’?

Gee, that’s confusing to explain. In other words, the ‘take visual actions out of world rule’ is simply declared and placed as a rule that preempts the usual ‘every turn stage rule’ and then the ‘if acting fast, rule succeeds’ statement simply ties every visual action to that particular rule every time they are called (by virtue of them being ‘acting fast’ actions)?

The extension Modified Timekeeping exists to deal with such cases. This lets you specify any actions as “acting fast” (by default looking and examining) or put the phrases “take no time”/“take full time” anywhere in your rules to override Inform’s idea of what a “turn” is. It also makes implicit actions take time automatically.

What if he used a “check” (or a “before”, I get really confused on those) rule instead of an “instead” rule for his apple-cutting example? (and probably for every other “instead” rule he already has that he doesn’t want to take up a turn, and maybe necessitating a “stop the action” afterwards) Wouldn’t that pre-empt the action before it took a turn?

That’s pretty much my (uneducated) thoughts on this, given that everything in the Standard Rules uses a Check rather than Insteads (as I said, the Check for the kissing action seems to work properly–stopping the turn dead in its tracks), but I wanted confirmation of the inner-workings of I7 before rewriting everything, only to find that I was under a faulty assumption.

The default behavior of Inform is that time advances (turn count, every-turn rules) for both successful actions and unsuccessful actions. Time does not advance for parser errors like “I don’t recognize that verb” and “no such object”.

The Modified Timekeeping extension lets you change that.

(if you read this before, I rewrote it)

Huh. In that case, why isn’t the “block kissing rule” - the one alluded to in the first post, after the first quote - triggering the Every Turn?

The “you can only do that to something animate” message is a parser error, not a block rule. The grammar is “kiss [person]” which triggers a special case for the “that noun did not make sense” error when the token matches a wrong kind of thing.

Another interesting anomaly is that “going nowhere” counts as a turn, as well as “enter” and “exit” even when you don’t supply a noun (for enter) or when you’re not in anything (for exit).

Examining a non-existent noun doesn’t count as a turn either, nor does something like “climb microwave” which is met with “You can’t see any such thing.”

And yes, Modified Timekeeping has solved my problems (at least for now), I (am) was just trying to get a solid understanding of the mechanism behind it all.

The Before rules run before the check rules, and have utility.

The documentation suggests you want to use “Before” for something that shouldn’t even be tried. Obviously this giant plastic novelty key from the carnival won’t fit that standard door lock, the player isn’t even going to bother trying it at all.

Whereas, you’d use a “Check” for a normal key that the player actually tries to insert into the lock.

Why would you wan’t this sort of fine-grained pickiness?

Suppose the door is booby trapped with an electrical current when the player touches the knob: It makes sense that with an obviously fake key the player might have a whim to use it but stop themselves beforehand, realizing their idea will fail without actually making an attempt. With a more normal key, the player would be further imposed to attempt to insert the key, and thus be subject to the shock.

The author could carefully order the check rules so that they rule out the novelty key first, but it would be safer to put such an action in the “before” rulebook to make sure that the electric shock won’t happen when an attempt is made with the fake key, or broccoli, or Mr. Key, all being considered and ruled out by the player before trying the action as folly.

“Enter” and “go” by themselves fail out at the supplying-a-missing-noun stage. You’re right that this is a bit of an anomaly – a failure here is a parser error, but the parser has reached a later stage and it winds up running the turn sequence anyway.

“Exit” by itself is a full-fledged action (it can trigger getting out of a container, or going in the “out” direction). It doesn’t require a noun.

Also, Check rules apply to specific actions, while “Before” rules (like “instead” and “after”) are a single rulebook. So if you want a rule that runs before any action in certain circumstances, you need to run a “before” rule rather than a check rule for every action. For instance, if you want to record a list of everything involved in the player’s action whether or not the action actually succeeds, you need to do that in the Before stage so it works even if the action gets punted by a Check or Instead rule.

Rasputin, as for your question about how it works: I think that if the player’s command gets parsed, then the Every Turn rules run and time passes, no matter whether the rule gets cut off by a Before or Instead or something, or even one of the rules that runs between parsing and action (like the accessibility rules that prevent you from taking something you can see but not touch). (As long as it isn’t an out of world action like “save.”) Otherwise you get a parser error.

Whether the command gets parsed depends on whether it matches an Understand line. The understand line for taking is something like “take [something]”–where Inform only checks visible things to see if they can stand if or “something.” So if you type “take bloborosmo” it won’t match the line, you get a parser error, and the Every Turn rules don’t run. If you type “climb microwave” and the microwave is in another room then again “microwave” doesn’t match the [something token and you get the same error. If the microwave is visible it should run some rule that blocks climbing, and the Every Turn rules will run.

As Juhana pointed out, the grammar for kissing is “kiss [person]” so “kiss rock” doesn’t actually match the grammar line. You’re getting a special parser error there, and the every turn rules aren’t running.

But there actually is a line to understand “go” as going, without any nouns–this presumably is to give the author a hook for allowing “go” to be understood as taking the one exit that’s available where there’s only one exit, or something like that. So the command “go” by itself is successfully parsed, and the Every Turn rules run even though it doesn’t actually manage to generate an action. Something similar is true
for “enter” (which can be very useful for redirecting “enter” to going inside where appropriate). Going nowhere and exiting when not in something are actually run as normal actions–“exit” is a complete command, and there’s a rule to stop the exiting action when you’re not in anything; similarly “go north” is a complete command and there’s a rule to block it when north isn’t a valid exit.

(Sometimes people use tokens like [any thing] which can match any object that’s in play, not just the visible ones. For instance, people often use “go to [any room]” for fast travel commands, because they have to accept room names even when the rooms aren’t visible.)

Hope this is helpful! In short, definitely use Modified Timekeeping.

Not that it’s anything but academic, but doesn’t that mean Exit has an implied noun? If there’s no relevant container or inside room (supplying an ‘out’) then the action doesn’t do anything. It relies on a container/room object to make traveling happen, unlike, say, Jump which can be successful regardless.

It’s probably nit-picking in 99% of circumstances, but I seem to be a stickler for such inconsistencies. Regardless of whether or not these things have reason and sense in Inform world, it appears wrong from a player perspective. Similarly the distinction between “going through” and “entering” causes a lot of issues. It takes a lot of care to make it appear seamless (at least for me), but that’s a different post.

Thank you all for your responses. I think I have the understanding and answers I need, at least as pertains to this topic. I’ll be back to pick your brains when I hit my next stumbling block :slight_smile:

Well, strictly speaking the container that you exit isn’t a noun but an action variable for exiting. It’s not something that gets entered in the command, but something that gets supplied by the world model in order for the action to work. It’s kind of similar to the room gone to for going (which is also an action variable)–the going action doesn’t make sense unless there’s a room you’re going to, but the room isn’t specified in the command, so the noun is the direction and the room gone to is calculated by the rules for going that direction. (And, like exiting, if there isn’t any room or door in that direction then the action fails.)

This does sometimes cause issues and take some work to make it go more smoothly–Emily Short’s Modified Exit extension helps with some of the issues for “exit.” (I think some of its functionality has been folded into default Inform, too.) But sometimes this isn’t so much the noun/action variable distinction causing the trouble, as the fact that sometimes the player will want to be able to do the same thing whether or not they typed a noun.

You could make this more consistent by adding a new action, maybe “entrancing”, and then redefining the bare verbs “enter” and “go in” to this action.

I did this in Hadean Lands. I don’t remember the exact reason why.

Matt w, thank you very much for you explanation on Before and Check. I think I may understand it a bit better now!