Described actions in tables

In ex 219, a system for giving detailed score is detailed. The ending contains a warning:

This system is tidy, but limited: we cannot give actions interesting names in the score list, like “seducing the pirate’s daughter” or “collecting a valuable artifact”.

However, it seems more limited than that, permitting actions but not what the compiler terms “described actions.” so this is good:

table of causal anomalies
failed causality	total turns	description	failure response
going south	-1	"placeholder"	"placeholder"

but this is bad:

table of causal anomalies
failed causality	total turns	description	failure response
going south in the narrow corridor	-1	"placeholder"	"placeholder"

Is it possible to use described actions in tables without getting too wild? Or is this just one of those things?

[of course, “current action” is itself not “described”, either, so maybe it doesn’t matter

I’m putting “described” in quotes because I don’t think that concept is in the docs]

maybe I should just whip up some truth states/properties but keep the turn stamp approach…

An action is what a mathematician or computer scientist would call a 5-tuple, n-tuple being how mathematicians and computer scientists say “made up of n parts which, in combination, uniquely identify the tuple, i.e., if the values of all n parts for both X and Y are the same, then X and Y are identical: they both identify the same tuple.” Unless they’re feeling really inscrutable, in which case they might say instead that an n-tuple identifies a vector in n-dimensional space.

4 of the 5 will be very familiar:

  • the actor
  • the action name (e.g., waiting, opening, throwing it at)
  • the first argument, e.g., noun
  • the second argument, e.g., second noun
  • whether the act was requested

If you turn on the actions debugging command and say “bob, go north”, the output will describe it as “asking Bob to try going north” as if the player is the actor and “asking it to” is the action name and Bob is the noun, and “going north” is… something.

But asking it to isn’t really an action in the same sense as other actions, the compiler just plays some tricks to pretend that it is. The action that really results from ``bob, go north` has Bob as the actor, going as the action, and north as the noun from the start. But it also has action requested: true. If persuasion succeeds, the carry out requested actions rule transforms this into Bob’s action just by flipping action requested to false. Then Bob’s action is attempted and when it’s over, we restore the old action requested and conclude the player’s asking it to action.

Rule preambles can have descriptions of actions, but to assign an action to a variable or table column, you have to uniquely identify a vector in action-space by providing enough information for Inform to know all 5 values. We don’t usually think of it anything like that, because so many are implicit.

If you leave out an actor, the player is assumed, so for actions applying to nothing, their action names alone serve as fully-specified actions: thinking is yourself thinking. For things that take one argument, you need to specify it; for things that take two, you have to specify both. For requests, you would say, e.g., asking bob to try going north, uncoincidentally just like how actions’ output has it.

But you could simulate allowing specifying location by having another room-valued column, and if it’s not blank, your code tests whether both the action matches and the room gone from (if that’s the one you mean) matches the location in the table.

[ edited: erroneously said asking it for instead of asking it to in a couple places. They’re different action names. asking it for is the action name of the current action briefly when you, e.g., ask bob for spoon, but then the action is promptly converted to the same thing you get with bob, give me spoon, i.e., asking bob to try giving spoon to yourself. ]

[ edited further 'cause my inner pedant can’t stop: if you look up stored actions, you’ll see there are six parts, one being the text of the player’s command. If an action applies to a topic, then the topic understood is a snippet variable, and snippets only have meaning in relation to some particular command text, so Inform stores the command text itself instead of a meaningless snippet value. But those are all implementation details; conceptually the topic is just another argument, either first or second, and so I assert that it’s reasonable to describe actions in the abstract as a 5-tuple. ]


Yeah, as far as a table column is concerned I think you can only have what the docs call a stored action (which comprises action name, actor, noun, second noun, whether it was a requested action, the original command text used to evoke the action) or a part of a stored action (e.g. the action name part of a stored action, e.g. ‘entering action’) all of which are specific constant values.

The entry in the table must be a specific constant value: you can’t have a description of actions which might apply to a variety of different actions rather than a specific constant one (‘doing something to the comfy chair’) or an action pattern (roughly speaking, a description of actions that can be used at the start of an action-based rulebook, e.g. ‘entering the comfy chair in the Dungeon in the presence of the Spanish Inquisition for the third time’) which are not themselves values, or for that matter a named action pattern such as ‘unexpected behaviour’ after writing ‘Entering the comfy chair is unexpected behaviour.’

EDIT: Like Zed said, lol.


The action name part in that case would be the going action (I6 ##Go). It’s just described as “asking Bob to…” by the code for >ACTIONS because it’s a request.

There is some previous discussion on the nature of “described actions” at "Described action". There’s no way to store one, but zarf revealed a trick to allow assignment of a description of things at run-time, which can be considered to be a piece of a described action tuple.

Unfortunately, the compiler won’t accept a description of things as a column type for a table, but if you’re prepared to get kludgey there are ways to make use of stored descriptions.


Thanks everybody for the explanations. They’re very helpful.

My code for tracking certain types of play information in RTE was messy and hard to read. There were lots of states tracked. By the end, there were multiple tables. I had to create these things at the very beginning of development when I had no experience with Inform. Or programming of any kind, really.

By the time I came to dislike my method, it had its hooks in everything. Redesigning something that was very stable and functional was too big of a risk, so it stayed as it was.

I’d like to pare all of that back this time. I could write to the table in action processing, that’s one option, though I lose the benefit of checking current action against a table. Maybe I’ll make some custom actions. At least then I’ll have clear stuff in RULES and ACTIONS tracing as well as the index. I can foresee making some general rules applying to all of these special actions as a group, too.

I think I’ll experiment with things like:

Being crushed by statues is an action applying to nothing.
Being crushed by statues is creating a temporal paradox.

Instead of going south in the narrow corridor when the number of adversarial stoneworks is greater than zero:
	try being crushed by statues.

report creating a temporal paradox:

Thanks again, everyone!

1 Like