Traditionally Easyacts only supported pre-set variables of a single character nature. While the most triggers still support these basic preset variables, newer triggers now use more readable named variables. For instance $i traditionally was a variable whose contents were a text pointer to entity for which the script was defined. While this can still be used, the more object oriented nomenclature of @this, or @self is preferred. These can also be written using $ but to break from the past it is suggested that all variables use @ instead of $ (similarly for function $. has been deprecated in favour of %). Additionally, script authors can now declare variables of their own naming on the fly.

There are currently five types of variables used in the Worlds of Carnage. The first two are types used by BlobbieScript. This style should always be denoted with the '@' marker such as @foo. These types of variables are only known to the script in which they appear, meaning two different scripts, even two different instances of the same script, will see a different value for @foo. As I have said there are two types, script variables can be declared as static, if so their values are remembered from one script instance to the next (and subsequently can be shared by multiple instances of the same script). The programmer needs to take care when declaring static variables since ANY variable in the static expression will become static and can thus block normal script variables.

Another type of variable is the entity variable. Entity variables can be applied to a rooms, mobiles, or objects. Entity variables can be set using %setEntityVar(), retrieved using %getEntityVar(), and unset using %deleteEntityVar(). These variables are a great way to share information across multiple scripts, especially quest, or game information. For convenience three other functions exist: %setVar(), %getvar(), and %deleteVar(). These are a shorthand for accessing the entity variables of the script owner. For instance:

The fourth type of variable is persistent. These variables are saved and can be restored even after a crash. Such variables can be used to ensure an object is unique or to save ownership of some residential portion of the world. There is a multitude of uses for such data. When saving a persistent variable, the variable is shared amongst all entity instances with the same vnum. These variables are manipulated with the following functions:

The fifth and final variable type persists in the player's save file. These are known as player vars and can be set for players, objects, and rooms. The following functions are used to manipulate their values:

Player vars set on a room are exactly the same as saved vars since rooms can't be saved to player files, but only one instance of a room with a given vnum can ever exist. The following table summarizes the variable types:

Scripts are fired when events occur. These events can be triggered by a player, a signal, or for a multitude of other reasons. There exists a set of default variables (many cryptic due to backwards compatibility) that are instanciated to facilitate knowledge of what elements played a key part in the firing of the script. These variables are listed below: