Trigger Variables are global system-event-based callfunction triggers. If they are blank, or if they are set to a string that isn't a vc function name, nothing happens. But if they are set to a vc function name, awesome magic happens!

trigger.onStep
trigger.afterStep
trigger.beforeEntityScript
trigger.afterEntityScript

The Step Triggers

If trigger.onStep is set to a vc function name, that function will be called everytime the player entity crosses a zone activation border, regardless of if a zone is about to be activated. If a zone will be activated, this function occurs right before that zone's script goes off.

If trigger.afterStep is set to a vc function name, that function will be called everytime the player entity crosses a zone activation border, regardless of if a zone is about to be activated. If a zone was activated, this function occurs right after that zone's script goes off.

Both trigger.onStep and trigger.afterStep's assigned vc functions will have access to a proper event.tx and event.ty, regardless if a zone gets activated. Note that this is a change in behavior, as event.tx and event.ty are now updated at a new point. If this breaks anyone's day, please let me know.

These two triggers are good for things like dealing with poison and tintinabar-style effects and step counters, which are more dependant on the act of walking than on any specific zone. I was brought to implement this specifically because there was no good way to deal with decrementing the "steps to battle" counter for Sully, and this seemed like an idea whose time had come.

The Entity Activation Triggers

If trigger.beforeEntityScript is set to a vc function name, that function will be called before any entity's onActivate script is called.

If trigger.afterEntityScript is set to a vc function name, that function will be called after any entity's onActivate script is called.

Both trigger.beforeEntityScript and trigger.afterEntityScript's assigned vc functions will have the proper event.tx, event.ty, and event.entity values available to them, just like the entity's onActivate script does.

These two triggers are great for handling universal pre- and post-conditions for entity onActivate events. Specifically, in Sully it was getting tiresome to have to tell the game to forbid the menu as the first line of every entity's onActivate script, and it was getting tiresome to tell the game to re-allow menus afterwards. If you forgot any of these, you basically created a gameplay bug! Awesome, eh?