Action definitions

Is there a page that defines all the actions that can happen in an Understand “x” as…like the [xxxx] nouns that can be used …E.G. something…etc.

Thanks

Index -> Actions. The “Commands” list shows what the player can actually type.

If you want the things like [something] specifically, that’s under “Tokens”.

Ok Ive read over them somewhat. Unless Im wrong,an NPC in one of these definitions of new commands would be referred to as a [something]

[someone], usually. Unless you want to be able to refer to things that are not people as well.

Though you can still do special-casing in some situations – for example in one story I have a statue that you can talk to. Normally the talk action only lets you talk to people, but I overrode it for this one thing since I didn’t want it to otherwise be treated as a person.

The name for the specific [xxxx] things is “tokens of grammar.” The standard ones are discussed initially in section 17.4 of Writing with Inform, “standard tokens of grammar.”

A list can be found in Index -> Tokens. It’s worth noting the first sentence there:

In addition to the tokens listed below, any description of an object or value can be used: for example, “[number]” matches text like 127 or SIX, and “[open door]” matches the name of any nearby door which is currently open.

(The rest of this post may not be necessary for what you’re trying to do, so don’t worry about it if it isn’t.)

However, it’s often a bad idea to restrict your tokens like this. Take this:

Treasure Hall is a room. A chest is a kind of container. An ornate chest is a chest in treasure hall. The description of the chest is "It appears to be have some sort of explosive mechanism attached to it. You will have to UNTRAP it." A jewelled sword is in the ornate chest. 

A chest is usually closed and openable. A chest can be trapped or untrapped. A chest is usually trapped.

Instead of opening a trapped chest:
	say "The chest explodes and kills you!";
	end the story saying "You have died".


Untrapping is an action applying to one thing. Understand "untrap [chest]" as untrapping.

Check untrapping a not trapped chest:
	say "[The noun] isn't trapped." instead.

Carry out untrapping a trapped chest:
	now the noun is untrapped.
	
Report untrapping:
	say "You deftly remove the trap from [the noun]."

This yields:

Transcript

Treasure Hall
You can see an ornate chest (closed) here.

x chest
It appears to be have some sort of explosive mechanism attached to it. You will have to UNTRAP it.

untrap chest
You deftly remove the trap from the ornate chest.

open chest
You open the ornate chest, revealing a jewelled sword.

untrap sword
You can’t see any such thing.

x sword
You see nothing special about the jewelled sword.

It’s bad that it said you couldn’t see the sword at the end! The problem is that the token [chest] means it’s only looking for chests that match the word “sword,” and when it can’t find one, it tells you you can’t see any such thing.

The better approach is to use the generic token [something] and to write a Check rule that stops the action when the noun isn’t a chest:

Treasure Hall is a room. A chest is a kind of container. An ornate chest is a chest in treasure hall. The description of the chest is "It appears to be have some sort of explosive mechanism attached to it. You will have to UNTRAP it." A jewelled sword is in the ornate chest. 

A chest is usually closed and openable. A chest can be trapped or untrapped. A chest is usually trapped.

Instead of opening a trapped chest:
	say "The chest explodes and kills you!";
	end the story saying "You have died".


Untrapping is an action applying to one thing. Understand "untrap [something]" as untrapping.

Check untrapping when the noun is not a chest:
	say "[The noun] isn't something that can have a trap." instead.

Check untrapping a not trapped chest:
	say "[The noun] isn't trapped." instead.

Carry out untrapping a trapped chest:
	now the noun is untrapped.
	
Report untrapping:
	say "You deftly remove the trap from [the noun]."

You can also define new tokens as in section 17.13 of Writing with Inform. This is pretty much only useful in conversation actions and other actions applying to text rather than things. (Or for prepositions, I guess, which is what the example given uses it for.) The documentation mentions

Understand "red bird/robin" or "robin" as "[robin]". 

which is useful if you want to capture “tell Jane about red bird.” But if the robin is an actual thing in the game world you can write

Understand "red bird/robin" or "robin" as the robin. 

without needing to create a token. (And you don’t need to include “robin”–the thing’s name is automatically understood.)

Ok so I get all that but am still having issues. I read through the manual but cant find a specific example to my problem.

I cannot get this to work

Understand “steal [things inside ] [something]” as stealing it from.

Any help would be great.

What problem exactly are you running into? This seems like it should work, though you might want a “from” between the two tokens.

(“Should work” meaning this is a sentence the compiler will accept, so the problem seems like it must be about it not behaving some way you want or expect it to do).

Stealing it from is an action applying to two things.
Understand "steal [things inside] [something]" as stealing it from.

This compiles fine. Though as Mike said, you can end up with some parsing ambiguity problems unless you put another word in between, such as steal [things inside] from [something]. What problem are you actually having?

Yes this compiles. Bascially what Im trying to do is this.

Worker is an NPC
Worker carries a key
I need the player to steal the key from the worker.

Also is there a way to see inventory of npc?

I mean, this works, though I think this approach is a bit weird because an object carried by a character isn’t inside the character – but so long as you don’t have a Check rule that actually enforces the noun to be inside the second noun, it works. But it sounds like there might be some confusion on what Understand statements do, which is help the parser figure out how to translate input into actions. Like, look at this code:

Understand “steal [things inside] from [something]” as stealing it from.  Stealing it from is an action applying to two things.

Understand "steal [thing] from [person]" as pickpocketing it from.  Pickpocketing it from is an action applying to two things.

The worker is a man in the dungeon.  The key is carried by worker. 

The chest is in the dungeon.  The amulet is in the chest.

Carry out stealing it from:
	Now the player carries the noun;
	Say "Stolen."
	
Carry out pickpocketing it from:
	Now the player carries the noun;
	Say "Pickpocketed."

Using tokens helps Inform distinguish between two different uses of STEAL, and redirect it to two different commands. So you get this output:

You can see a worker and a chest (in which is an amulet) here.

>steal key from worker
Pickpocketed.

>steal amulet from chest
Stolen.

So that’s helpful if you want to model pickpocketing a person and stealing from a container differently – you can write different Check and Carry Out rules and so on to do things like requiring a lockpick for stealing or say that you can only pickpocket while you’re being sneaky. But if what you’re actually trying to do is restrict the STEAL command to only work on the contents of a container, you should do that with a Check rule – tokens won’t get you there. Hopefully this is helpful – sorry, I think I’m still not 100% clear on what’s not working for you!

Oh, and for your second question, I think the idea is to manage how the player sees what NPCs carry (like the worker carrying the key)? If so, I think Section 3.24 of Writing With Inform has the goods.

Note that in addition to the above rules, you’ll also want something like this, otherwise you’ll be able to steal any item in the vicinity from any nearby container/person, regardless of whether they actually have it or not:

Check stealing it from:
	if the noun is not in the second noun:
		say "That doesn't seem to be inside [the second noun]." instead.

Check pickpocketing it from:
	if the noun is not carried by the second noun:
		say "But they're not carrying that." instead.

(Initially I thought that the stealing action wouldn’t have this problem because [things inside] will only parse things actually inside the container, but that turns out not to be the case – both need it.)

Or if you’d rather be fancier and use a gendered pronoun, you can:

		say "[regarding the second noun]But [they're] not carrying that." instead.

Also, section 3.24 doesn’t help here. Concealment is about scope, not about display – possessions are not concealed by default, which simply means that they’re in scope and can be referred to in commands. Were you to conceal the possessions of the worker, that would stop you from stealing the key from them (you can't see any such thing) but it still wouldn’t have displayed anything.

Usually, the best way to reveal possessions of NPCs is on closer examination (unless they’re supposed to be blatantly obvious at a casual glance):

The description of the worker is "He looks bored, occasionally even almost nodding off.  [if the worker carries the key]A large key protrudes from his coat pocket.[end if]"

It is possible to do this other ways (such as a similar display as the container), though, or by defining a general rule to print possessions of NPCs, if you’re going to have a lot of stealing in your story.

Oh, I hadn’t realized that! The giant warnings about the [any things] token in 17.4 made me draw the negative inference that [things] was relatively safe. Time to make sure all my Check rules are up to snuff…

[thing] / [things] only lets you refer to things “in scope”, so they have to be items carried by the player, in the same room, or otherwise visible on other things in the same room (like NPCs, supporters, or open containers). [Or otherwise brought into scope by special rules, but that’s getting complicated.]

So (without the Check rule) you couldn’t steal the key from the chest if the chest was in a different room from the worker, but with both in the same room, you could. It’d also let you steal the key from the worker or the chest repeatedly even though you already had it.

[any thing] / [any things] ignores scope, so it’d let you steal the key regardless of what rooms you and it were in. It’s really only intended for testing actions like purloin and perhaps special conversational actions, not for any normal in-world actions – hence the warning.

When you’re writing this sort of extra action, it can help to look at the existing Check rules used by similar actions – in this case, taking – and seeing which ones ought to apply in your case as well. In fact, if the standard rule has a suitable error message you can simply use the same rule directly, for example:

The can't take what's already taken rule is listed in the check stealing it from rules.

Another option would be to just treat steal as an alias for the existing taking/removing actions; this way it inherits all the same rules and behaviours. Then you just need to special-case some of them – by default the Standard Rules will block taking things from NPCs, but you can define conditions that override this, for example. (This wouldn’t be the right choice if you wanted to treat taking and stealing differently, however. It’s still possible to distinguish them, but it’s more awkward; better to use separate actions.)

1 Like

That’s what I would have thought, too, and in principle, it should work, shouldn’t it? If one leaves out the pickpocketing sections, it does seem to work:

The Study is a room.

The chest is a container in the Study. 
The gem is in the chest.

The box is a container in the Study. 
The book is in the box.

The pencil is in the Study.

Stealing it from is an action applying to two things.

Carry out stealing it from:
	now the player carries the noun;
	say "Stolen.".
	
Understand "steal [things inside] from [something]" as stealing it from.

The transcript looks okay:
(Edit: I mean, it looks okay with regard to the specific parsing issue at hand. I agree with what was said above by Matt and others, that from a game design perspective, “you can’t see any such thing” is not a good message for the player here.)

Study
You can see a chest (in which is a gem), a box (in which is a book) and a pencil here.

>steal gem from box
You can't see any such thing.

>steal book from chest
You can't see any such thing.

>steal pencil from chest
You can't see any such thing.

>steal box from book
You can't see any such thing.

>steal book from box
Stolen.

>steal gem from chest
Stolen.

So, if it doesn’t work in the larger example, that must be due to some interaction with the pickpocketing grammar line and action? (I don’t know)

Interestingly, I also noticed that even in the minimal example something weird happens when we come into a certain situation where the parser supplies a missing second noun:

>take pencil
Taken.

>steal gem
(from the pencil)
Stolen.

>steal book
What do you want to steal the book from?

:thinking:
Maybe I’m overlooking something here, but it’s fairly curious at first glance. Note that this seems to happen only when the player has taken the pen, and only for the first item which we try to steal.

When we add Gavin’s “Check stealing it from” Rule given above in the thread, it stops this, so it’s not a real problem, but still weird:

>steal gem
(from the pencil)
That doesn't seem to be inside the pencil.

Interesting. When the rules are changed to these:

Understand “steal [things inside] from [something]” as stealing it from.
Understand "steal [things inside] from [someone]" as pickpocketing it from.

Then stealing from the chest will correctly refuse to steal something not inside (albeit with not the best message, as you said), while pickpocketing from the worker will still steal something not carried. Changing [someone] to [person] results in both actions passing through successfully. (It doesn’t seem to matter whether pickpocketing uses [things inside] or [things]; either one works, although it may change which order it parses things in. I suppose technically the most correct token to use would be [other things].)

It still seems like a good idea to have explicit Check rules to prevent that regardless, though. And in fact if you’re happy with the standard message then you can just steal [pun intended] that one too:

The can't remove what's not inside rule is listed in the check stealing it from rules.
The can't remove what's not inside rule is listed in the check pickpocketing it from rules.

Also interestingly, this standard rule does seem to work as expected for both stealing and pickpocketing, although the standard message is perhaps less interesting (but it isn't there now).

As far as I’m aware, the default rules for guessing a second noun will pick a single portable object in the room if there is exactly one, or failing that try the same thing in the inventory. (This despite the fact that it’s very rare for the second noun to ever be an inventory item – but I think it follows the same rules for guessing the noun as well.) At that stage in the parsing it’s not aware that it only makes sense to match a container, for example. Only after there’s more than one possible object in either place will it consult the does the player mean rules (at which point you can hint that it should be looking for a container), or give up and ask for disambiguation.

2 Likes

Without looking into the internals or trying to figure out exactly what’s going wrong, one issue may be that the “[things inside]” token is pretty unusual. There’s an entire section of the parser (Parser Letter F) devoted to looking ahead when the first token is “multiinside” ([things inside]) or “multiexcept” ([other things]).

…in fact, it looks to me as though Parser Letter F contains a hard call to “NOUN_TOKEN” which I believe corresponds to “[something]” as opposed to “CREATURE_TOKEN” which I think is “[someone]”. So that might be a hint as to why things get weird when you have a “[someone]” token? It looks to me as though the parser is really expecting the line to be [things inside] followed by a preposition followed by [something].

This might also explain why “[things inside] [something]” wasn’t working; I think the parser really wants a preposition in between the [things inside] and [something] tokens.

Anyway, the thing about “[things inside]” is that in the Standard Rules it’s used only for the “removing it from” action, which is in turn basically there to allow “TAKE ALL FROM DESK” to take all the things that are on the desk and nothing else. So I think it’s a good idea not to try to use it in a new action!

(Similarly, the [other things] token is used only for inserting it into, and I think the rationale is so you can type “PUT ALL INTO BAG” without trying to put the bag into the bag.)

It’s probably a better idea to define stealing with “steal [something] from [someone]” and write check rules to make sure that the second noun is carrying the noun.

1 Like

If each NPC is only carrying one stealable thing (or you don’t mind requiring them to name only one object to steal at a time), then yes, this simplifies things quite a bit.

If, on the other hand, you want the player to be able to steal all from guard to take the guard’s lunch as well as his key, then it’s a bit trickier. [other things] is still probably the best way to go for that. By default it will end up trying quite a few silly combinations (that should at least be refused gracefully, with an appropriate check rule) – but it’s possible to further improve this through use of deciding whether all includes rules.

Ah, this might be one of the cases referred to in the manual, where it says (in §17.4):

“[someone]” matches the same possibilities as “[a person]” would, but the parser handles it a little better in cases of failure.

Thanks, Matt and Gavin, for the investigations and clarifications!

1 Like