I’m new to inform, and forgive me if this is a repost (I searched but couldn’t find the topic). I have this code:
moving is an action applying to one thing. understand “move [something]” as moving.
the cell is a room.
The secret cache is a container in the cell. " Your secret cache is hidden behind a loose stone.". understand “cache”, “hole”, “stone”, “loose stone” as secret cache.
an escape plan is in the secret cache.
instead of moving the secret cache: try searching secret cache.
when executed, the command ‘move stone’ returns ‘nothing obvious happens.’ instead of listing the contents of the secret cache. I’ve implemented the same exact logic for an action called ‘looking behind’ and it works fine. Why not for moving?
The command “move [x]” already carries a meaning. It’s synonymous with “push”. In some cases, you might want to abolish the old command before giving it a new meaning. That can be done by making it refer to “something new”:
Understand the command "move" as something new.
In this instance though, there’s no need to change things that much. As “move” already redirects to “push”, you could do this instead:
The Cell is a room.
The secret cache is a container in the cell. "Your secret cache is hidden behind a loose stone." Understand "cache", "hole", "stone", "loose stone" as secret cache. It is fixed in place.
An escape plan is in the secret cache.
Instead of pushing or pulling the secret cache: try searching secret cache.[/code]
You can also use this method of combined actions to make it easier on the player:
[code]The Cell is a room.
The secret cache is a container in the cell. It is openable and closed. "Your secret cache is hidden behind a loose stone[if the cache is open] most of the time. Right now it's open, revealing [a list of things in the cache] inside[end if]." Understand "cache", "hole", "stone", "loose stone" as secret cache. It is fixed in place.
An escape plan is in the secret cache.
Instead of pushing or pulling or searching the secret cache when the cache is closed: try opening the secret cache.
When the secret cache is open, there’s really no point in pushing or pulling the stone, but “search cache” still works in its default mode. When the cache is closed, though, searching the cache also opens it.
EDIT: You may ask yourself if there’s an easy way to see which actions apply. The command “actions” (or “actions on”) is useful for that, as it prints the name of subsequent actions as they fire.
I suspected ‘move’ already carried a meaning, but ‘instead of moving x’ didn’t compile until I tried to declare it as an action. Now that I know it redirects to ‘push’, I could see that ‘instead of pushing x’ compiles properly.
Thanks for demonstrating the open/close alternative, as well!
And for the ‘action on’ tip! somehow I missed that trick in the documentation…
A good trick to know is this: if you type “actions on” in your game (while running in the Inform 7 development environment), you get to see all the actions that the game attempts to take. So if you first type “actions on” and then “move stone”, you will see something like “[pushing the secret cache]”, and you will know that the verb is called “pushing”.
Shouldn’t this be considered an Inform bug? Since the grammar line “move [something]” is already assigned to an action, shouldn’t the compiler issue an error message on an attempt to use that grammar line to refer to a different action?
I can see that the compiler doesn’t want to check this sort of thing with nouns. We want to be able to define a flop-eared puppy and also a bag of puppy kibble without running afoul of the usage of “dog” to refer to two different objects. But verbs are different, I think.
Should this be reported as a bug? As a feature request?
It’s common to redefine actions with the same word but different tokens. For example, defining “move [person]” creates an exception to the usual grammar, with people going to the new action while everything else goes to the original action. (The synonymity of “push” and “move” is preserved.)
The question is what happens if you define another “move [person]”. The usual Inform plan (for phrases, rules, etc) is that this is not an error – one of the uses overrides the other.
It would seem to be most useful if the author’s definition overrode the library’s definition. I’m not sure why it doesn’t. Maybe it’s getting caught by a “first defined” technicality.
While technically not a bug, I sort of agree with you. It would be nice if the compiler would give you some warnings. Still compile fine, but then say 'oh by the way you tried to define “move [something]”, I thought you’d like to know that move is an already known verb."
A question about the index: The original post made me think, “Hm, I think that’s the default response for pushing.” So I went to the Actions tab of the index and looked up “pushing,” where I saw this:
but not “move [something].” Is this just a bug in the Index, or is there a reason why “move [something]” doesn’t show up?
In fact, a lot of synonyms don’t seem to be showing up. Just check attacking, for instance, which has quite a number of synonyms. None show up. And even worse, check out the two swearing actions, where Inform 7 irritatingly states that he is not going to tell us. (That really annoys me.)
It seems as of these lists are handcrafted rather than automatically generated? Which sounds like a really bad idea?
They may be automatically generated after all.
It seems that only the verbs defined by an ‘Understand “VERB” as verbing’ statement will be detailed under its specific action in the Actions A to Z part of the Actions Index. Those defined by an ‘Understand the command “ACT” as “VERB”’ won’t, though they will be found under the Commands A to Z part of the Actions index (with the exception, again, of the curses—you won’t find them even in the pdf-version of the Standard Rules, but of course you find them in the Standard Rules extension file that Inform actually uses).
Here they are, by the way: bother, curses, drat and darn; shit, fuck and damn
I think the difference between these two ways of creating commands is that the first way (understanding the verb as an action) creates a special syntax line for that verb to check during parsing, while the second way (understanding one verb as another) only provides alternative ways to get at one and the same syntax line.
But why only verbs created in one of these ways should be listed in the actions details is of course another matter. It would certainly be convenient to have the mere synonyms listed there, too.
