All atoms in LexyQuest are defined with three variables: trigger, triggername, and triggermessage. For most objects, these values will be null. When the map is initialized, any object that has a text value set for the trigger is added to a list of objects called "triggers".

Whenever an action is performed on an object that has an assigned triggername (actions include: a mob is awakened or killed, an item is picked up or dropped, a room or turf is entered or exited, a room is searched, etc.), a proc searches the triggers list for any object whose trigger var matches the object's triggername. If the trigger object has a value set for triggermessage, it also checks to make sure the action (passed along through the triggering proc as a message) matches the triggermessage.

For instance, let's say we want a wall to disappear when a golem is slain. For this to work, we need to make a new instance of the turf/wall, and of the mob/golem. The golem needs a triggername, and the wall needs a trigger. It doesn't really matter what we decide to call these, as long as they're the same thing. For simplicty's sake, we'll just call them "golem".

Now, whenever the mob we've labeled "golem" is activated, it checks for triggers with the same label. We don't want the wall to actually vanish until the golem is dead, though, so we need to specify a triggermessage for the wall. The message passed along when a mob is slain is simply "slain."

Turning into a floor tile is the default action for walls... turning into a wall, by contrast, is the default action for floors. This makes it easy to make toggleable passageways. Similarly, the default action for closed doors is to open and for open doors is to close. Of course, all of these actions are accomplished by creating a new turf on top of the old... but by setting a flag called "inheritance", you can make the new turf inherit the same trigger values as the old one.

Each type of object in the game has a default action when triggered. Some have more than one possible, based on the message passed along. For instance, a triggered door would open by default, but could be locked, if the right triggermessage was passed along.

There are also trigger objects, which are simply used to modify a trigger's message. They have the variables trigger, triggername, triggermessage, and a special variable called "outgoing", which is the message they pass along. For instance, let's say we want a door to unlock when a monster is slain. We can't link the monster directly to the locked door... if we did, we couldn't specify any triggermessage, since "awake" and "slain" mean nothing to a door. We can make a trigger object, which checks for the "slain" message, and triggers the door in turn. You would also use a trigger object if you wanted a normal door to lock, rather than open... no object by itself generates a "lock" triggermessage.

Trigger objects can also be used for special effects: they can send text messages to the person who started the trigger chain, the room in which the event is occuring, and/or the game itself. They can also trigger the end of the game. Features planned for them include adding conditionals, such as only activating if the character who started the trigger is (or isn't) a member of certain classes, or is or isn't carrying an object with a particular triggername.

This whole system might seem a little pointless and contrived, when there's a whole powerful programming language available for coding "special" mobs and turfs and areas and objs... but the idea is to allow such things to be soft-coded, so that completely new and original scenarios can be devised and run from within the game environment.