Persistent state

Variables reset every time a handler runs. To remember something between runs — a counter, a mood, a flag — you will need to write it to a game entity's persistent state: a set of string-keyed slots attached to a creature, object, or room.

Persistent state is not part of the variable namespace. You never read a slot with $name; you read it with recall. The slots live as long as the entity does.

store — write a slot

store <entity> <key> <value>

recall — read a slot

recall <entity> <key>

Returns the stored value, or null if the slot was never written (test with isnull).

forget — clear a slot

forget <entity> <key>

Deletes the slot; a later recall of it returns null again.

Slots are not game attributes

store / recall touch only the script's own slots. They do not read or change the entity's real game attributes — hit points, position, vnum, and so on are exposed read-only through builtins like level, position, and vnum. A store $self 'hp' 50 writes a slot named hp that has nothing to do with actual hit points.

(The marker-tag builtins tag / untag / hastag are a separate mechanism, independent of store / recall.)

Example

after command (say) {
  store $self 'visits' 1
  do "say visits before forget: [recall $self 'visits']"
  forget $self 'visits'
  if [isnull [recall $self 'visits']] {
    do "say slot cleared"
  }
}

Stores 1, recalls it (the mob says "visits before forget: 1"), then forgets it so the next recall is null (the mob says "slot cleared").

A common pattern is to store on one event and check on another:

after command (say) {
  store $self 'state' 'gossip'
}

after command (gossip) {
  require [eq [recall $self 'state'] 'gossip']
  do "say I remember you saying hello first."
}

The gossip handler runs its body only if a prior say left the state slot set (see require).

See also