Uses: Basically, if there's a situation where
you want to 'turn off' a trigger, or more specifically, an event
based on a trigger, for a period of time, or simply forever,
there are four primary methods for doing so.
*Note: You are not actually enabling/disabling the trigger.
You are Enabling/Disabling the Event itself in Kismet.
One-Time Use: If you have, let's say, a trigger
tied to a 'Touch' event, and you only want it to go off once,
the easiest way to do so is to set the Events' MaxTiggerCount
to 1, which is what it is by default. If you also want it to
'Untouch' once, then set the MaxTriggerCount to 2 - 1 for the
touch, and 1 for the untouch.
Multiple Use: There are thre primary ways
to do this. The first way is with Toggles, the second with a
gate, and the last with variables.
Toggles: Basically, the system will be an event that
fires off a trigger touch event, that will then route into a
toggle to turn off the event. Then, after a delay, the signal
will go back into the toggle and turn the touch event back on.
The delay I have is basically where you would put all the stuff
that the trigger event is firing off. Also, set the MaxTriggerCount
to 0 so it can be triggered again and again and again. Like
so:
|
|
Gates: Gates are fantastic tools. In this situation,
we'll use a trigger touch and untouch. Let's pretend we have
something that can be used, but we don't want it used, unless
a player is outside of a certain location. We'll set up a trigger
used event, and a trigger touch event, and then we'll add a
gate. In this example, we won't actually be disabling the event.
We'll allow the trigger to fire as often as it likes, but we're
going to stop the signal from proceeding until the player leaves
the area - the untouch event fires. Then the Used Event can
proceed through and fire off the delay. Again, the delay is
where the special stuff would happen. Remember to set the MaxTriggerCounts
to 0 so they can fire again and again. Like so:
|
|
Variables: There are a few ways we can do this. Basically
we're going to use variables to determine if a player is in
a location and, if so, allow a Used event to fire based on that
determination.
If you're dealing with a simple situation where you only need
to measure 1 player, then you could use Boolean
variables. Let's set it up so that True = inside, and False
= outside. They player will be outside by default so the initial
value will be false. When the player tries to use the trigger,
we'll Compare
the boolean, and if it's set to inside, we'll allow the signal
through. If the player's outside, we won't do anything. Like
this:
|
|
If we need to measure multiple players, booleans won't quite
cut it using this method. So we'll change to integers.
Whenever a player enters the area, the integer count will go
up by 1, and whenever they leave, it will go down by one. When
the player uses the trigger, we'll Compare
the B value to the A value which is controlled by the set integer
actions. if the integer is 1 or more, it will allow the event
to fire. Like so:
|
|
None of these methods is 'better' or 'worse' than any of the
others. You'll just need to figure out which one is better suited
to what exactly you're trying to do.
|
