Triggers and Events in a Nutshell

Triggers in Zot.

The Proper form

Strength and Conditioning

Hot Action Zot

Misc. Trigger-like thingies

Tricks of the Trade

For those of you that are the "Will this be on the test?" type, here are the cliff's notes about triggers and events to help you get started right away.

Triggers:
Triggers are things that happen, as Skeezix explained to me, a maximum of once per engine tick.  In other words you won't be using triggers to have a hot floor sizzle away your character's hit points for the time he's sitting on the tile.  A trigger "watches" the game for something to happen, and when it happens it will do the action(s) you tell it.  Picking up a sprite (item) can happen one time, and it's watched for, it doesn't just happen out of nowhere.

Events:
Events are the dynamic versions of triggers.  They still do an action, or action-group, when something happens, but it's more of a "this can occur, but it can happen anywhere, not just this tile".  The best example is impact damage, since an enemy hitting you can happen many times per tick, and you may for example accumulate 10 damage in one tick, whereas a trigger would have the damage applied once per tick.  Events also define variables automatically, like when doing math they will change the variable for you.  (variable-subtracting _from.health will automatically change "health" to accomodate the action, like taking 10 off of it each time)

Important event side note about performance!  Remember to place and time your events well, as too many firing at once can seriously hurt your framerate!

I've given triggers their own section as they can be quite complicated, and I haven't spent enough time on them!  The options, inputs, and types of triggers are listed under the Commands section, but their syntax and logical use will be put here for reference.

Note that the tables are actual functional examples, just seperated neatly so you can see each line clearly :)

Note also that some tips and tricks can be found at the bottom, along with pointers on good and proper usage!

Triggers, like everything else in Zot, relies on how you make it.  It's true there's an order to everything, especially in Zot, since misuse of a trigger will have you spinning in circles to debug it!  Without further adue, here's the correct form of a basic trigger:

trigger	a * or an integer	trigger begins and is named, using a * means the trigger is unnamed, like a global trigger for setting gravity or some other trigger you don't need to refer to later
on-player-entry	(x,y)	some type of condition, if this then do the action
on-floor	floor name	you can add more conditions, if condition 1 AND condition 2, then do the action
action	action-group # or action	some type of action, listed on the Commands page, or an action-group number, which is defined after the tile map.
trigger	end

Basically, it's an ordered operation, like in geometry.  If this, then do this, or if this AND this, then do this.  Note if you use multiple conditions like on-statements, they are assumed as "true", so on-player-entry 3,5 assumes the player enters 3,5.  This may seem obvious, but some times there are reasons for it to work the other way!

I think the theory of a trigger is kind of self-explainitory.  If you pull the trigger on a gun, it fires, and the same applies to a trigger in Zot.  Actually the terms are the same too, as a trigger "fires" when the condition you put in is met, and does an action.  Here is a good time to review conditions and actions, since you'll meet them in every single trigger you write!

Conditions:
     A condition is what the trigger looks for to happen before it does an action.  It's basically like saying "wait until the player pulls the trigger, then fire the gun.".  Most conditions are on-statements, one is an engine-variable, and a special kind are when-statements (also called events).  I explained events in the Commands section, but I'll do so again here for reference.

On-statement Conditions

• on-floor     floorname     spritename
  If this sprite is on the floor...
  
• on-no-sprite     floorname     sprite
  If none of this sprite is left...
  
• on-player-entry     x,y
  If the player enters this tile...
  
• on-pickup-sprite     spritename
  If the player picks up this sprite...
  
• on-variable-lt/gt/ne     variablename     ##
  If this variable is LessThan, GreaterThan, or NotEqualto this value...

Engine Variable Conditions

• _ticks_since_begin     ####
  After this many ticks...

When-statement Conditions (Events)

• when-collide     sprite     sprite2
  When these two sprites touch...
  
• when-dies     sprite
  When this sprite dies...
  
• when-ltezero     variable
  When this variable is less than or equal to zero...

Definition of an Event:  So what's the big difference between a conditional on-statement and an event?  An on-statement is scripted to happen, like a trap firing, or something happening after X seconds.  An event however doesn't depend on something predetermined, and it is looked for during play, such as the movement of two sprites is completely unpredictable, but when two of them touch, they damage each other.  This is dynamic conditioning, but we call them events :)

Actions, obviously, are things performed by the engine when a condition is met.  After you pull the trigger of a gun, it propels a bullet out of the barrel.  Here the pulling of the trigger is the condition, since it won't fire without it, and firing a bullet is the action.  Simple huh?

However it does get more complicated with action groups.  Not much more complicated really, all an action group is, is a block of actions pooled into one entity, so you can bypass certain problems and keep your triggers neat and tidy.

Actions (which are all listed in Commands, with examples)

• goto-text
• end-dialog
• post-message
• action-group
• post-message
• variable-add
• variable-sub
• variable-set
• trigger-change
• goto-floor
• make-sprite
• kill
• end-game

Action-grouping:  Action groups are used to stuff a list of actions to be done at the same time into one pack.  You'd use these for, say, a handful of triggers that do the same group of actions.  Eventually Zot will support multiple actions in a trigger, but for frequently used groups of actions it's still best to use one of these!

action-group	name
post-message	"First action"
post-message	"Next action, etc."
action-group	end

To use this group, you'd put in your trigger "action-group     name" and blam, you've got all of your actions in one small package!

There are some neat Zot commands that aren't really triggers, but still do something, so I put them in this bit here.

Text-menus

text-menu	name	Names the menu
preamble	"Is this helpful?"	Initial text the menu says or asks you.
"Yes"	goto-menu     name2	First choice on the menu and what choosing it does.
"No"	end-dialog	Second choice, same deal.  Up to 10 choices.
text-menu	end

Buttons - These are basically tiles that cause triggers, and are defined before the tile map.  They work alot like sprites, but can have only four states, and you specify which state it advances to.Later on I've explained a trick to avoid screwing up buttons by having triggers point to an undefined tile.

button	1	Button tile-block in the tilemap*
state	alpha	Anim state to start in
anim_state	alpha	Properties for state alpha
anim_image	button1	Image to use**
toggle_door	1	You can use actions or action-groups here.
option	trigger_entry	Options, chances are you will only need this one.
exit_state	beta	State to go to after this is triggered.
anim_state	beta	Properties for beta.
anim_image	button2	Image to use**
exit_state	alpha	Exit-state, can use this to loop it.
toggle-door	1	Actions...
option	trigger_entry	Options...
button	end

*The name of the button is a defined tile on the tilemap, so if your button is 0 on the tile map and it's name is buttonQ, you'd name the button block "button buttonQ"

**For the image to use, it's of course from the image-list.  Since there are no frames/steps to these animations, you need a seperate image for each state!

I'll get a list of button option inputs from Skeezix later, but it looks like only trigger_entry is supported, which means when the player enters this button it activates.  What more do you need though?

Triggers have some problems, especially when dealing with order of declaration.  In other words, the order you write things in the config affects your triggers, since you can't tell a trigger to do something if it hasn't been defined!  This is mainly the deal with tiles like buttons, which have actions with them, like level changes.  You can avoid that by using action-groups, which are defined after the tile map, that way the tile map (for a goto-floor action) is defined and your trigger can refer to it :)