definition    
 why use it?  
  my solution 
  the scripts   
  the .zip file  

prefabs
'office'
[email protected]

 First thing: a directional trigger is a prefab that sends one message while
the player goes thorugh it in one way and another message if the player passes
through it in the oposite direction.
 Let me highlit the word 'prefab' in the phrase above. Ok, now what uses can
the average Avp2 mapper find for this contraption?

 Well, for start, one of this babies can change the music played in a
SP mission. Place it at the entrance to one section and make it send 
messages like 'msg player (musc DefaultMood Ambient AmbientX)' when the
player goes in one way and messages like 
'msg player (musc DefaultMood Ambient AmbientY)' when he goes back.
 Another thing this baby can handle is sending visibility messages like:
'msg NiceTerrain0 (visible 1)' or 'msg NiceTerrain0 (visible 0)' to make
a SP level run at (very) high framerates, despite the high poly count for
the terrain mentioned.

 What I came up with is a set of 6 triggers:


 The core holds the triggers the player actually touches (called 'Sensors')
and two aditional triggers, that lock and unlock the sensors.
 The other two triggers are the triggers that should be used by the mapper.
Simply place all your messages there. Set up delays etc., I don't care;
you can make all the alterations you want, these are the triggers that will
recieve trigger messages from the core. So if something goes wrong, you're
the only person to blame :-)

 As you'll see from the scripts below, the working of this DirTrigger is 
pretty simple: 
  - as the player moves one way, it touches one sensor and then the other.
  - The sensor touched first will trigger the FBLockAll0 trigger and thus
    lock itself and the second sensor. It also triggers the timed trigger
    FBUnlock0, to unlock both sensors after the player has moved away 
    from it (2 seconds). The last target the sensor has it's his own 
    trigger, in our case say Trigger_goingForward0.
  - when the player reaches the second sensor, he/she 'll find it locked
    (remember? the first sensor touched locked it!). Thus, his own messages
    will not be send.
  - going the other way, the player will touch the second sensor first and
    reach the first one while locked and so on.

 
 The scripts are pretty simple. These are the settings for one of the two 
sensors:


 
 The other sensor is almost identical, except the last target, which will be
Trigger_goingForward0.

 Settings and targets for the FBLockAll0 trigger:



 The reason why I set the PlayerTriggerable to FALSE is simple: the trigger
lies in the middle of the contraption so it might get touched by the player;
but I don't want the player to trigger it, I want the sensors to do it.

 Settings and targets for the FBUnlockAll0 trigger:



 Remember? The Unlock trigger must be timed!


 What can I say in the end: the .zip file has three such triggers, for each
3 possible directions: - front <-> back 
                       - left <-> right
                       - up <-> down 

 The way they were build allows you to copy-paste them repeatedly, without
worrying about the scripts and the fact that all the CORE sections will
trigger the same triggers; they are completly isolated and 'copy-paste'-safe.
 Use them. Love them. Mail me :-)
 Just kidding about the mail part.