The Actionstrip, or Astrip, is the starting point for any interaction (excluding combat). It is responsible for telling the game what to do with an Astrip icon is selected for a particular NPC or scene element.
The Astrip system takes its information (its database) from a human-readable ascii file in a syntactical format called SNTX (described in the Interaction system page). It is from this database that Astrip will reference when the game system requests Astrip to display some text.
However, there are some Actions that are not completely relevant to displaying of text, such as ‘hax’, or ‘loot’, which call on other game systems to perform the action. In the case of ‘loot’, the Trade menu comes up, and usually that the end of it. These sort of ‘action’ Actions are done in the game system itself, and is not necessary to define it in the Actionstrip db.
The Convo system syntax was developed after the original Actionstrip syntax. Actionstrip has now been brought into the same line with Convo, so refer to the Convo system page for more general information about the syntax.
Actionstrip (Astrip) databases
The Astrip database dicts each have an owner. The source data may come from multiple files. The main difference between the Astrip’s and the Convo system’s source-reading is that while Convo reads each source as a separate NPC/entity, the Astrip can combine multiple sources and merge them into a specified owner. This will be explained later below.
The basic tokens are:
?refers to a Condition statement; this is used as prefix to a possible CSV of different Conditions
$refers to an Accomps Condition
@refers to a State Condition (a State condition refers to a state value of the NPC itself)
-refers the variant of an Action
~refers to the directive or function of an Action (usually DoAccomps)
,Concats AND or & for Conditions
|concats OR or | for Conditions
By default when the Astrip sources are read into dicts they assume their owner to be the name of the actual file they are reading. They follow the syntax
astrip_<name>.md and thus the
astrip portion is stripped out and the
<name> is used as the dict’s owner name.
This allows some flexibility while authoring the sources. It is possible to separate one owner’s source, while combining multiple owners in one source.
For example, in the case of Chuck the Checker, we keep all of its Astrip interactions into one file
astrip_chuck.md. We no longer need to use the
== symbol to prefix the keys because this already assumed.
['++look ?@ok'] = look=How much would checking wood would a Checker like Chuck check if Checkers like Chuck ever checked wood?
There are instances, however, when we want to define multiple owners in one source, as when we are using ‘look’ to inspect multiple things in one scene. It’s harder to manage separate sources when all they contain are very short lines of description.
We do this by specifying the owner using the
['==screen1 ++look'] = look=Sub-Rail schedules dating back 10 years flicker weakly on the tv screen.
When the parser sees
==screen1 it knows to create another dict for a new owner and then puts the Action
look in there.
C2 dict processing
There is peculiarity with C2’s method of creating objects (e.g. dicts), and for the purposes for reference, I will include here the method of iterating over the source.
When C2 creates an object, it does not properly exist as an object to be accessed by any function besides the functions that run underneath the sub-event that it is on. Thus, when the parser creates, say, 2 dicts one after the the other, the first dict is essentially ‘lost’ and inaccessible until the next ‘top-level’ event is encountered; the system is ‘refreshed’ and the objects created in one event are now properly recognised.
Because of this, we need to process the source twice. The first pass is to create the dicts. The second pass is to populate the data in the dicts.
First pass: create dicts
The source is read:
- Take note of the default owner which is the parsing of the file being read.
- Create a dict immediately for this owner. Set the
- Add this dict’s owner to a CSV string called
created_owners_listthat will be used to compare if a dict has been created for a particular owner.
- The source is iterated, looking for
==which is the symbol of ‘owner’. If an owner if found, check if it has been created by doing a
find()-like function in
- Set the dict’s
- If it wasn’t found, then create the dict and append the new owner to
After that’s done, we should have a slew of dicts with their proper
owner variables populated.
Second pass: populate data
The source is read again from a top-level event:
- Take note of the owner based on the file being read.
- For each key, if no
==is found, then the owner is assumed to be the default one.
==is found, then parse for that owner, and pick the proper dict based on the
- Populate data as needed.
Action and popup type
The Action in the Astrip key refers to the selection that the player would have made.
['==bench3 ++look']= look=A bench. Nothing special.
The above shows that if the player uses ‘look’ on the bench, the value will be used.
Notice that the value has a further directive called ‘look’. This is called the popup type. This is a preset used by the game system to determine how the text will look like. In ‘look’, for example, this preset is meant use the cyan text, and ‘talk’ will use a different font with another colour.
The Condition system here is the same as you would find in the Convo system. Go to the Convo system page for more details.
Astrip uses variants in the same way as the Convo system.
==ticket_machine ~vars::2 ==ticket_machine -1 ++look:: look=The ticket machine is powered up, but you think it's run out of tickets to dispense. ==ticket_machine -2 ++look:: look=Looks like something from the future.
Like Convo, it needs the
~vars directive to know how many variants it is allowed to look for.
-2 modifier signifies which variant is being defined.
DoAccomps is a way to tell the Astrip system to add or set a key in the Accomps dict.
Like DoAccomps, but sets the state of the NPC instead.